Security at Every Boundary in the Chain

CRM to network, one boundary at a time: what crosses, who is authorised, how it is authenticated, what the receiver may do, and how it is audited.

The order chain from Lead-to-Cash, with one question set 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 security lens on the order chain. Read the right-hand column as the questions an architect should be able to answer at each boundary before the interface is built.

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.

Where the answers usually go wrong

COM → SOM: the shared secret

The most common finding in an O2A estate: one long-lived API key, shared by every integration, with full rights. Compromise it and an attacker can create, modify or cancel any service order. Zero trust says this hop gets a scoped, short-lived token like any other.

ROM → Network: the human shortcut

Activation fails, and an engineer logs in directly to fix it. Without PAM the fix is invisible: no session record, no link to the order, and inventory now disagrees with the device. The shortcut is a security gap and a data gap at once.

TM Forum and 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.

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.

Key Takeaways

Ask the five questions at every hop, in design, before the interface exists.
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.