Should organisations compose identity layers instead of forcing one product to do everything?

Why This Matters for Security Teams

Composing identity layers is not an architecture preference so much as a control boundary decision. When one product is asked to do authentication, token issuance, session policy, and fine-grained authorization, failures become harder to isolate and governance becomes harder to prove. That is especially true for non-human identities, where the blast radius is often tied to how long a token lives, how broadly it can be reused, and whether the policy engine can evaluate context at request time.

NHIMG research shows how often this goes wrong in practice: Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which makes over-loaded identity products even riskier because they tend to preserve broad access rather than separate duties. Current guidance also aligns with NIST Cybersecurity Framework 2.0, which pushes organisations toward clear responsibility, access governance, and measurable control outcomes instead of single-tool convenience.

In practice, many security teams encounter over-permissioned service accounts only after a vault, gateway, or login stack has already become the de facto policy layer, rather than through intentional design.

How It Works in Practice

A composed stack usually assigns separate roles to separate layers. One layer establishes workload or user identity, another issues or brokers credentials, and a third evaluates whether a specific action should be allowed. For NHIs, that separation matters because an API key, certificate, or token should not also be the place where policy logic lives. The identity layer proves who or what is making the request; the authorization layer decides whether the request fits the current context.

For mature environments, that often means combining workload identity with short-lived credentials and policy-as-code. Workload identity gives cryptographic proof of what the system is, while just-in-time issuance reduces the value of stolen secrets. Policy evaluation can then consider attributes such as environment, service, request type, time, and sensitivity. This is consistent with the control themes in the Top 10 NHI Issues, which repeatedly surface overlong lifetimes, weak visibility, and poor offboarding as root causes.

• Use one component for authentication or workload attestation.
• Use a separate broker for short-lived token or secret issuance.
• Use a distinct policy engine for runtime allow or deny decisions.
• Keep audit trails at each boundary so failures can be traced cleanly.

Where possible, pair the composed model with just-in-time access and revocation workflows, because the 52 NHI Breaches Analysis shows how quickly static credentials become long-lived attack paths once they are embedded in automation. These controls tend to break down in legacy monoliths that hard-code authentication, authorization, and session handling into one release cycle because every policy change becomes an application change.

Common Variations and Edge Cases

Tighter separation often increases integration overhead, so organisations must balance stronger governance against more moving parts. That tradeoff is real, especially where teams want low-friction developer experience or where a legacy platform cannot easily externalize policy. Best practice is evolving here, and there is no universal standard for how much should sit in a gateway versus a centralized policy service.

Some environments still use a single platform for identity and authorization at small scale, but that approach becomes fragile when the same platform must manage humans, NHIs, partner access, and machine-to-machine workflows. The risk is not just feature overlap. It is coupling: if login, token lifetime, and policy are bundled together, any change to one control can unintentionally weaken the others. For enterprises with third-party integrations, this is even more sensitive because compromise often starts outside the core boundary, as shown in NHIMG’s Cisco DevHub NHI breach research.

Composed identity also works better when organisations need different assurance levels for different workloads. A batch job, a CI/CD runner, and an AI agent may all require distinct issuance rules, revocation timing, and policy evaluation depth. Where those requirements diverge, forcing one product to do everything usually creates hidden exceptions that erode security over time.

Related resources from NHI Mgmt Group

• When should organisations prioritise Zero Standing Privilege for non-human identities?
• What is the difference between code scanning and runtime identity monitoring?
• How can organisations reduce secret leakage in ServiceNow at scale?
• How do organisations reduce false positives in secret detection pipelines?