Security at Every Boundary in the Chain
Last updated 12 Oct 2026
At a glance
The Lead-to-Cash order chain, with one set of five security questions asked at every hop. The systems do not change; the answers do: a customer with MFA at the top, a scoped service-account token in the middle, a recorded privileged session at the bottom.
The picture
How it works
The five questions
- What data crosses the boundary? Personal data at the top of the chain; technical parameters lower down. Classification decides the protection.
- Who is authorised? A person by role, or a system by scope. “Any authenticated caller” is not an answer.
- How is the interaction authenticated? OIDC for people, OAuth client credentials or mTLS for systems, PAM for privileged sessions.
- What can the receiving system do? The scope of the token, not the reach of the network, bounds the damage of a compromise.
- How is the action audited? An immutable record of who did what, joinable to the order: see tracing an order.
How the answers change down the chain
At the channel, a person authenticates, usually with MFA through a customer identity platform, and the data is personal. Between COM, SOM and ROM, systems call systems, so the identity is a service account and the control is a scoped, short-lived token or mutual TLS. At the bottom, ROM and engineers reach network elements through the management plane, where access is privileged and every session should be brokered and recorded.
TMF APIs define payloads, not security
The Open APIs (TMF620, TMF622, TMF641 and the rest) define payloads and operations, not authentication. TM Forum’s guidance assumes OAuth 2.0 bearer tokens at the gateway; scopes and roles are the operator’s design decision. An API being TMF-conformant says nothing about whether it is secured.
Where authorisation is enforced
A gateway can check that a token is valid and carries a scope. It cannot see account ownership, order state or region, which is what many real rules depend on. Those checks have to happen inside the system that holds the data, which is why mixed estates usually layer both.
Who owns what
| Entity | System of Record | System of Engagement | System of Reference | Notes |
|---|---|---|---|---|
| Customer identity and credentials | CIAM / customer identity platform | Digital channels, apps | CRM | CRM holds the customer record; the identity platform holds how they prove who they are. |
| Workforce and service-account identities | IAM platform | — | API gateway, each system | One service account per integration, not one shared key for all of them. |
| API scopes and access policy | API gateway policy (ideally as code) / IAM | — | Each system’s internal authorisation | Coarse scopes at the gateway; fine-grained rules live where the data is. |
| Privileged sessions to network elements | PAM platform | — | SIEM, the order or ticket it relates to | A session with no link to an order or ticket is an unexplained change to the network. |
| Audit trail of order actions | SIEM / central log store | — | COM, SOM, ROM | Each system emits; the central, immutable copy is the one joined to the order identifier. |
In practice
Packaged BSS/OSS products often support OAuth and mTLS but ship with simpler defaults, and integrators under delivery pressure keep them. Replacing a shared key later means touching every integration that uses it, so the cheapest time to ask the five questions is in design, before the interface exists.
The trade-off
What it solves
A consistent way to secure every hop in the order chain, so each boundary has a known identity, a bounded scope and an audit record joinable to the order.
What it does not solve
- Vulnerabilities inside the systems themselves; a well-scoped token does not patch the application behind it.
- Inaccurate inventory left behind by changes made outside the order flow.
- The choice of roles and scopes, which TMF leaves to the operator.
What it adds
- Token issuance, rotation and expiry for every system-to-system integration.
- Authorisation logic split between a gateway and the systems behind it, which has to be kept consistent.
- PAM brokering adds a step to break-fix work that engineers will push back on during incidents.
Architecture decision
Where should authorisation be enforced for the order APIs: at the gateway, or inside each system?
Gateway only
Choose when systems are vendor packages you cannot change and the gateway can express the rules you need.
Each system
Choose when rules depend on data the gateway cannot see: account ownership, order state, region.
Both, layered
Choose when coarse scopes at the gateway, fine-grained checks inside; the usual answer for an estate of mixed vendors.
Breaks if the gateway is the only check and an internal caller bypasses it. Every system then trusts anything on the network.
Takeaways
Key Takeaways
- Ask the five questions at every hop, in design, before the interface exists.
- The identity changes down the chain: a person with MFA, a scoped service account, a recorded privileged session.
- The COM → SOM boundary is where shared secrets hide; the ROM → network boundary is where humans bypass the design.
- TMF conformance covers the payload, not the security of the call.
Check yourself
Every integration into SOM uses the same long-lived API key with full rights. What is the risk, and what replaces it?Show answerHide
Compromising one integration lets an attacker create, modify or cancel any service order, and the audit trail cannot tell callers apart. Replace it with a service account per integration, each with a scoped, short-lived token (or mTLS), so the scope bounds the damage.
An engineer fixes a failed activation by logging in to the device directly. What two problems does that create?Show answerHide
A security gap, because without PAM there is no session record or link to the order; and a data gap, because resource inventory no longer matches the device.