How can organisations tell whether identity has really become the perimeter?

Why This Matters for Security Teams

The question is not whether identity exists in the stack. It is whether it actually decides access before network reachability does. In a real zero trust design, authentication, session policy, device or workload context, and authorisation must be evaluated at the gate, not after a connection is already trusted. NIST frames this as a shift from perimeter-based assumptions to continuous, policy-driven decisions in NIST Cybersecurity Framework 2.0.

This matters because many organisations still add identity controls on top of legacy network trust instead of replacing it. That creates a false signal: users may log in with MFA, but once they are on the network, broad lateral access remains. The same pattern applies to NHIs, where API keys, service accounts, and tokens often retain access long after the original trust decision should have expired. NHIMG research shows that only 5.7% of organisations have full visibility into their service accounts, which makes it difficult to prove that identity is really the perimeter when the most common identities are also the least visible, as covered in Ultimate Guide to NHIs.

In practice, many security teams discover that identity was not the perimeter only after a compromised account, token, or service credential has already been used to move laterally.

How It Works in Practice

To test whether identity is the perimeter, follow the decision path for a real request. A strong model places enforcement at the point of entry, where identity proof, session state, privilege, and context are checked before the user or workload reaches sensitive systems. That means the network may still carry traffic, but it no longer confers trust.

For human access, this usually means MFA, device posture, conditional access, and least privilege are evaluated together. For NHIs, the equivalent is workload identity plus short-lived credentials, with policy evaluated at request time rather than granted once and assumed forever. Current guidance suggests that identity should be tied to cryptographic proof of what the workload is, not just what secret it holds. In practice, that often means OIDC-based workload authentication or SPIFFE-style identity, paired with policy-as-code enforcement.

In NHIMG’s Ultimate Guide to NHIs — What are Non-Human Identities, the core pattern is clear: long-lived secrets and broad standing access undermine perimeter claims because the trust decision is not re-evaluated. By contrast, identity-centred architectures are supposed to revoke or re-authorise continuously, especially when the session, service account, or agent changes behaviour. This aligns with the Zero Trust direction in NIST Cybersecurity Framework 2.0, where trust is explicit, dynamic, and context-aware.

• Check whether access to critical apps is blocked until identity and context are verified.
• Verify that privileged sessions are time-bound and re-authorised, not just authenticated once.
• Confirm that service accounts use short-lived tokens or workload identity, not reusable static keys.
• Test whether policy changes take effect at request time, not only at login.

These controls tend to break down in flat networks, service-mesh exceptions, and CI/CD pipelines that still rely on static secrets because trust is granted too early and revoked too late.

Common Variations and Edge Cases

Tighter identity enforcement often increases operational overhead, requiring organisations to balance stronger assurance against developer friction, legacy compatibility, and response speed. That tradeoff is real, especially where older applications cannot evaluate context at runtime or where machine-to-machine traffic was never designed for interactive auth.

Best practice is evolving for agentic and automated workloads. There is no universal standard for this yet, but current guidance suggests that static RBAC alone is too coarse when an agent can chain tools, change intent, or request new scopes mid-task. In those cases, identity is only the perimeter if authorisation is re-evaluated on each action and the credential lifetime matches the task lifetime. This is why NHI governance cannot rely on a single login event.

Edge cases also appear when organisations confuse authentication with perimeter control. A successful login does not prove that identity is the perimeter if network segments, shared admin paths, or implicit trust between services still allow broad reach. NHIMG’s 52 NHI Breaches Analysis shows how often tokens and service credentials become the real attack path once trust has been overextended. The practical test is simple: if a compromised identity can still move freely after revocation should have occurred, identity is a control layer, not the perimeter.

Related resources from NHI Mgmt Group

• When does a machine identity become a compliance problem?
• When does secret exposure become a broader identity risk?
• How can organisations tell whether identity posture sync is actually working?
• How can organisations tell whether identity assurance is actually working?