Zero trust perimeters are only as strong as identity controls

At a glance

What this is: This is an analysis of zero trust security perimeters, arguing that identity, device, and application controls must work together and that identity is the foundation of the model.

Why it matters: For IAM and NHI practitioners, it reinforces that service accounts, tokens, and agent identities cannot be governed by perimeter thinking alone.

By the numbers:

• Compromised credentials remain one of the most common entry points for cyberattacks, according to Verizon DBIR 2025.
• Only 5.7% of organisations have full visibility into their service accounts.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read Beyond Identity's analysis of security perimeters in zero trust

Context

Zero trust starts with a simple idea: do not trust the network boundary, verify every access attempt. In practice, that shifts attention from perimeter firewalls to identity, device posture, and application authorization. For NHI governance, the same logic applies to service accounts, API keys, certificates, and AI agents, because they now behave like first-class identities in the access chain.

The article argues that identity is the foundation of zero trust because device and application controls inherit whatever confidence the identity layer provides. That framing is broadly correct, but it also exposes the governance gap that many programmes still miss: non-human identities often authenticate silently, persist longer than human sessions, and evade the review cadence applied to users. That is typical of immature IAM programmes, not an edge case.

Key questions

Q: How should security teams govern non-human identities in a zero trust model?

A: Security teams should classify non-human identities as first-class identities, assign ownership, and apply least privilege, rotation, and offboarding controls to them. Zero trust only works when service accounts, API keys, certificates, and agents are reviewed as part of the identity perimeter rather than hidden inside infrastructure or application stacks.

Q: What is the difference between device trust and identity trust?

A: Device trust evaluates whether the endpoint or workload meets a security baseline, while identity trust evaluates who or what is requesting access. Both matter, but identity trust is the more fundamental control because a compliant device can still be used by a compromised identity, and a non-human identity may not have a traditional endpoint at all.

Q: Why do non-human identities complicate zero trust architecture?

A: Non-human identities complicate zero trust because they often authenticate silently, operate continuously, and hold privileges that outlast a single user session. That makes them easy to miss in reviews and difficult to govern with user-centric controls alone, so programmes need separate inventory, authorization, and lifecycle processes for them.

Q: When should teams use just-in-time access for privileged actions?

A: Teams should use just-in-time access whenever a task requires elevated permissions that should not remain standing all day. It is most effective for administrative actions, sensitive application changes, and recovery operations, because it reduces the time window in which a compromised identity can cause damage.

Technical breakdown

Identity perimeter: why authentication now carries the most weight

The identity perimeter is the decision point that determines whether an access attempt is legitimate before any resource is exposed. In zero trust, that means authentication quality matters more than network origin. Phish-resistant MFA, least privilege, and contextual policy are meant to reduce the chance that stolen credentials can be reused at scale. For NHI governance, the same control logic should apply to service accounts, API keys, and machine certificates, because they also establish who or what is acting. The failure mode is not just stolen login data. It is trust granted to an identity that is never revalidated, never scoped tightly enough, and never retired on time.

Practical implication: Treat every persistent credential as an access path that needs policy, monitoring, and lifecycle control.

Device trust and the limits of posture checks

Device trust tests whether the endpoint connecting to a service meets a minimum security baseline, such as encryption, updates, and active protection. That works well when the user session depends on a managed device, but it becomes less complete when the access is coming from automation, cloud workloads, or AI agents that do not have a conventional endpoint posture. In those cases, security teams need a different attestation model. The lesson is not that device trust is useless. It is that device controls cannot compensate for weak identity controls, especially where non-human identities authenticate from infrastructure rather than laptops.

Practical implication: Extend attestation to workloads and agents instead of assuming endpoint checks are enough.

Application perimeter and privileged action security

The application perimeter is where authorization becomes operational. Role-based or attribute-based rules determine what a caller can do once authenticated, and step-up authentication is often used for sensitive actions. In NHI environments, that same pattern should be translated into task-scoped authorization and just-in-time access, because machine identities often hold broader privileges than they need. Shared Signals Framework style event sharing can help enforce revocation or step-up decisions faster, but only if the upstream identity is already classified and governed correctly. The main architectural point is that application controls reduce blast radius, they do not repair broken identity trust.

Practical implication: Use application authorization to contain impact, but fix identity governance first.

Threat narrative

Attacker objective: The attacker aims to turn a single compromised identity into broad operational access across identity, device, and application layers.

1. Entry occurs when attackers reuse stolen credentials, weak MFA, or phishing access to authenticate as a user or a non-human identity.
2. Escalation follows when the initial identity has broader permissions than necessary, letting the attacker move from login to privileged actions.
3. Impact comes when application access and API calls are abused to exfiltrate data, disrupt services, or manipulate workflows.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity is the control plane for zero trust, not just one perimeter among three. The article is correct to separate identity, device, and application, but the deeper lesson is that every other layer inherits its assurance from identity quality. If service accounts, tokens, and agent credentials are weakly governed, downstream controls only limit damage after the fact. Practitioners should therefore treat identity governance as the operating assumption for zero trust, not a supporting service.

Non-human identities make the zero trust model harder because they collapse the distinction between user access and machine access. A service account, API key, or AI agent often authenticates without a visible human session, which makes traditional user-centric reviews incomplete. That creates a runtime governance gap: the access exists, but the owner, purpose, and expiry are often unclear. Teams need to classify machine identities explicitly and manage them as a separate trust population.

Privileged action security is where zero trust either becomes real or remains rhetorical. Step-up authentication and contextual policy help at the application layer, but only if the identity behind the action is already bounded by least privilege and lifecycle controls. Otherwise, sensitive actions still ride on standing access. The practical conclusion is that zero trust for NHI must combine strong authentication, short-lived authorization, and revocation discipline.

Identity blast radius is the right lens for evaluating modern access risk. The concern is no longer only whether an identity can authenticate, but how far it can move if compromised. Excessive privilege, long-lived secrets, and weak offboarding turn a single credential into a systemic incident vector. Security teams should measure how far a compromised non-human identity can travel before controls stop it.

Zero trust programmes that ignore NHI governance will overstate their maturity. Many organisations can show device compliance and application policy while leaving machine identities under-owned and over-permissioned. That mismatch produces a false sense of control because the most automated identities are often the least visible. Practitioners should close the gap by placing NHI inventory, rotation, and entitlement review inside the zero trust programme itself.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• For a broader breakdown of the identity-risk pattern, see 52 NHI Breaches Analysis, which connects poor visibility to real-world compromise paths.

What this signals

Identity blast radius is the metric most teams still fail to measure. If a service account or agent credential can reach multiple applications, then a single compromise can turn into a cross-domain incident even when device controls are in place. For practitioners, that means entitlement mapping and revocation speed matter more than checkbox zero trust coverage.

The next governance step is to separate human trust from machine trust in policy design. Service accounts, certificates, and AI agents should be reviewed on different cadences and with different evidence than user accounts, because their authentication patterns and failure modes are not the same.

If you want a useful benchmark for programme maturity, start by measuring how many non-human identities are owned, reviewed, and rotated on schedule. The operational question is no longer whether zero trust exists, but whether it covers the identities that actually move data and trigger actions.

For practitioners

• Map non-human identities into the zero trust model Inventory service accounts, API keys, certificates, and AI agents as separate identity classes, then assign ownership, purpose, and expiry to each one. Use this inventory to align access review and offboarding with the identity perimeter rather than treating machine identities as infrastructure artifacts.
• Enforce phish-resistant authentication for interactive access paths Require hardware-backed or otherwise phishing-resistant factors for any human or administrative path that can reach privileged systems. For machine access, replace shared long-lived secrets with stronger workload identity and scoped credentials where possible.
• Convert standing privilege into just-in-time access Remove persistent elevation for high-risk actions and issue time-bound access only when a task requires it. Pair that with approval, session logging, and immediate revocation when the task completes to keep the blast radius small.
• Treat device posture as necessary but not sufficient Continue checking encryption, patching, and endpoint protection for managed devices, but do not assume those checks govern cloud workloads or AI agents. For non-human actors, add identity attestation and runtime policy so device trust does not become a blind spot.
• Tie application policy to lifecycle events Make revocation, rotation, and access review trigger on role changes, workload decommissioning, and secret exposure. Application rules should reduce impact, but lifecycle controls are what stop dormant credentials from becoming future entry points.

Key takeaways

• Zero trust fails in practice when identity governance is weak, because every other control layer inherits that weakness.
• Non-human identities expand the attack surface by creating long-lived, often invisible access paths that standard user controls do not fully cover.
• Practitioners should focus on ownership, least privilege, rotation, and just-in-time access to reduce identity blast radius.

Key terms

• Identity Perimeter: The identity perimeter is the access boundary defined by who or what is requesting entry, not by where the request comes from. In zero trust, it is the point where authentication, authorization, and risk context decide whether a caller can proceed.
• Non-Human Identity: A non-human identity is any machine- or software-based actor that authenticates to systems, including service accounts, API keys, tokens, certificates, workloads, bots, and AI agents. It should be governed with ownership, least privilege, lifecycle controls, and revocation discipline.
• Just-in-Time Access: Just-in-time access is a pattern that grants elevated permissions only for the time needed to complete a specific task. It reduces standing privilege, shortens exposure windows, and makes compromise less useful because high-risk access expires quickly.

Deepen your knowledge

Zero trust identity and NHI governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a programme that has to cover both human and machine access, it is worth exploring.

This post draws on content published by Beyond Identity: Security perimeters in zero trust. Read the original.