Zero trust after the F5 breach exposes the limits of perimeter trust

At a glance

What this is: This is an independent analysis of how the F5 breach and CISA Emergency Directive 26-01 expose the limits of perimeter trust and accelerate Zero Trust adoption.

Why it matters: It matters to IAM and NHI practitioners because the same trust assumptions that fail in network security also fail in identity governance when access is static, broad, and poorly verified.

By the numbers:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.
• Only 5.7% of organisations have full visibility into their service accounts.
• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.

👉 Read Beyond Identity's analysis of Zero Trust after the F5 breach

Context

Zero Trust is a security model that removes the assumption of an internal trusted network and instead requires continuous verification of every access request. The F5 breach matters because exposed interfaces and outdated software created a path around inherited trust, which is the same governance failure IAM teams face when access is granted once and then left in place.

For NHI governance, the lesson is broader than network segmentation. Service accounts, tokens, certificates, and automated agents can become hidden trust channels if they are not inventoried, constrained, and monitored with the same discipline applied to users and devices. That starting position is typical, not exceptional, in distributed enterprises.

Key questions

Q: How should security teams extend Zero Trust to non-human identities?

A: Security teams should apply the same Zero Trust principles used for human access to service accounts, API keys, tokens, and automated workloads. That means inventorying every NHI, scoping privileges tightly, rotating credentials, and re-validating access conditions instead of assuming machine access is inherently safe.

Q: Why do NHIs complicate Zero Trust architecture?

A: NHIs complicate Zero Trust because they often rely on static credentials, broad permissions, and automated flows that bypass human checkpoints. If teams do not explicitly govern those identities, Zero Trust becomes partial, with the highest-volume access paths remaining least controlled.

Q: What is the difference between network segmentation and identity segmentation?

A: Network segmentation limits where traffic can move, while identity segmentation limits what an identity can do and which resources it can reach. Both matter, but identity segmentation is critical for NHIs because a compromised token or service account can move through authorised paths even when the network is segmented.

Q: When does Zero Trust fail to reduce breach impact?

A: Zero Trust fails when it is applied only at login or only to users. If service accounts, API keys, and automation still have standing privilege, attackers can exploit those paths without triggering the controls meant to contain them.

Technical breakdown

Why perimeter trust fails in distributed environments

Perimeter security assumes that traffic inside the network is trustworthy and that the main control point is the edge. That model breaks when applications, APIs, remote administrators, and third-party access paths are all part of normal operations. In the F5 case, exposed interfaces and outdated software turned trusted infrastructure into an attack surface. For identity teams, the technical parallel is static authorization: once credentials or device trust are accepted without re-evaluation, the control plane stops reflecting current risk.

Practical implication: Treat every access path as untrusted until continuously verified, including administrative, service, and automated access.

How continuous verification changes the access model

Zero Trust does not mean denying access by default, it means making access conditional on current evidence. That evidence can include MFA, device posture, software integrity, and session behaviour. The important shift is that trust becomes time-bound and context-bound rather than permanent. For NHIs, this is especially relevant because machine access often bypasses human checkpoints and relies on long-lived credentials or broad token scope. Continuous verification forces those identities back into the governance loop.

Practical implication: Map where access decisions rely on stale trust and replace those decisions with re-evaluation at session start and during runtime.

Micro-segmentation and least privilege for machine identities

Micro-segmentation reduces lateral movement by limiting which systems can talk to one another, while least privilege limits what each identity can do. For NHIs, the architecture should bind service accounts, workloads, and API clients to narrowly scoped permissions and explicit network paths. Without that design, a single compromised credential can become a cross-environment foothold. The F5 breach is a network example, but the same logic applies to identity estates: broad trust creates blast radius.

Practical implication: Combine network segmentation with role scoping and credential scoping so a compromise stays local rather than systemic.

Threat narrative

Attacker objective: The attacker objective was to gain durable access to strategic infrastructure and expand operational leverage inside trusted environments.

1. Entry occurred through exploitation of exposed interfaces and outdated software in F5 BIG-IP devices, creating an initial path into trusted infrastructure.
2. Escalation followed when attackers used that foothold inside an environment that assumed internal trust, increasing their reach across systems tied to the device.
3. Impact was the ability to threaten federal infrastructure and force emergency inventory, update, and hardening actions across affected assets.

Breaches seen in the wild

• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.
• Azure Key Vault privilege escalation exposure — Azure Key Vault Contributor role misconfiguration enabled privilege escalation.

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

NHI Mgmt Group analysis

Perimeter trust is now a liability, not a control. The F5 incident shows how quickly a trusted edge can become an attacker’s staging point when the control model assumes internal safety. That assumption also weakens identity governance because once an identity or device is trusted, teams often stop challenging that decision. Practitioners should treat trust as a continuously tested claim, not a network location.

Zero Trust only becomes meaningful when it reaches machine access. The practical failure in many programs is that users receive MFA and posture checks while service accounts, tokens, and automation are still granted broad standing access. That gap leaves the most scalable access paths outside the governance model. The right response is to extend continuous verification to every identity class, especially NHIs.

Identity blast radius is the real metric that matters after a breach. The core question is no longer whether an attacker can get in once, but how far they can move after getting in. Broad entitlements, long-lived credentials, and weak segmentation turn one compromise into a program-level failure. Practitioners should measure how much damage any single identity can do and reduce that radius first.

Reactive patching is necessary, but it does not close the governance gap. Emergency directives and accelerated remediation are appropriate responses to active exploitation, yet they do not solve the underlying trust model that allowed the exposure to matter so much. Security leaders should use the incident to justify architectural change, not just faster maintenance. The next control investment should reduce dependence on inherited trust.

From our research:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which leaves most machine access outside direct governance.
• A deeper case study is available in 52 NHI Breaches Analysis, where recurring credential and privilege failures show how hidden identities widen attack paths.

What this signals

Identity blast radius is becoming the decisive planning metric. For most programmes, the issue is not whether Zero Trust exists on paper, but whether a compromise can be contained to a small, observable set of identities and paths. That requires coordinated control over users, devices, service accounts, and automation.

With 97% of NHIs carrying excessive privileges, per the Ultimate Guide to NHIs, the operational question is no longer access approval alone. It is whether the environment can reduce privilege faster than an attacker can exploit it.

Runtime trust debt: environments accumulate access assumptions whenever credentials, certificates, and tokens stay valid longer than the risk model justifies. Practitioners should expect more pressure to tie identity governance to continuous verification, segmentation, and rapid revocation rather than static review cycles.

For practitioners

• Inventory trust-bearing assets and identities Build a current map of exposed devices, privileged accounts, service accounts, API keys, and administrative pathways. Include where credentials live, who can use them, and which systems still rely on inherited network trust.
• Enforce continuous verification for access decisions Require MFA, device posture validation, and session re-checks for interactive access. Extend the same discipline to machine access by limiting token scope and re-evaluating long-lived credentials on a schedule.
• Segment systems to reduce blast radius Separate management planes, production workloads, and third-party access paths so one compromise cannot traverse the environment freely. Pair segmentation with role scoping and short credential lifetimes.
• Prioritise NHI governance in Zero Trust planning Treat non-human identities as first-class participants in Zero Trust design. Align service account review, secret rotation, and offboarding workflows with the same rigor used for human access.

Key takeaways

• The F5 breach is a reminder that inherited trust still creates operational risk when the environment is exposed and poorly governed.
• Zero Trust only reduces breach impact when it covers both human and non-human identities across login, runtime, and revocation.
• Security teams should use this kind of incident to reduce identity blast radius, not just accelerate patching and device remediation.

Key terms

• Zero Trust Architecture: A security model that assumes no implicit trust based on network location or prior access. Every request is evaluated using current context such as identity, device health, and policy before access is granted or continued.
• Non-Human Identity: A digital identity used by software, services, workloads, or automated agents rather than a person. NHIs include service accounts, API keys, tokens, certificates, and AI agents, and they often carry broad privileges that require explicit lifecycle governance.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and administrative functions. In practice, it is shaped by privilege scope, credential lifetime, segmentation, and how quickly access can be revoked.

Deepen your knowledge

Zero Trust architecture for non-human identities is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are aligning machine access with continuous verification, it is worth exploring.

This post draws on content published by Beyond Identity: From Reactive to Proactive: A Practitioner's Guide to Zero Trust After the F5 Breach. Read the original.