Many organisations treat Zero Trust as a login problem and resilience as a separate recovery problem. In practice, both must work together because post-authentication access can still be abused. A useful programme verifies continuously, constrains lateral movement, and protects critical services during active compromise.
Why This Matters for Security Teams
zero trust fails when it is reduced to authentication theatre. The real risk starts after login: service accounts, API keys, workload identities, and privileged sessions can still move laterally if access is too broad or too persistent. That is why resilience cannot sit in a separate “disaster recovery” lane. It has to assume active compromise, contain blast radius, and keep critical services operating under pressure.
NHIMG research shows that 90% of IT leaders say properly managing non-human identities is essential for a successful zero-trust implementation, yet only 5.7% of organisations have full visibility into their service accounts. That gap explains why teams often miss the identities that matter most. The NIST guidance in NIST SP 800-207 Zero Trust Architecture is clear that trust should be continuously evaluated, not assumed once at sign-in. For the NHI side of the equation, the Ultimate Guide to NHIs shows why unmanaged machine identities are a direct Zero Trust failure mode.
In practice, many security teams encounter lateral movement only after an incident has already bypassed perimeter assumptions, rather than through intentional verification and containment design.
How It Works in Practice
A workable programme treats Zero Trust as an operating model across identity, device, workload, network, and data controls. Access is granted with explicit context, kept as narrow as possible, and rechecked when conditions change. For humans, that means strong session controls and least privilege. For non-human identities, it means short-lived credentials, workload attestation, rotation, and hard separation between environments.
Resilience enters the design at the same time. The question is not only “can this workload authenticate?” but also “what happens if it is compromised anyway?” That leads to practical controls such as segmentation, service-to-service policy enforcement, immutable logging, rapid secret revocation, graceful degradation, and recovery paths that preserve essential services. NIST SP 800-53 Rev. 5 supports this approach by tying access control, auditability, and system integrity into broader protection and recovery outcomes.
In many environments, the most useful sequence is:
- Identify the critical services, identities, and data flows that would cause the largest blast radius if abused.
- Map human and non-human access paths separately, because service accounts and API keys often persist far longer than expected.
- Apply policy that can stop or step up access when posture changes, rather than relying on one-time authentication.
- Test containment and recovery together so revocation, failover, and incident response work under live conditions.
NHIMG’s Guide to SPIFFE and SPIRE is useful here because workload identity is often the missing control layer between Zero Trust policy and real service-to-service enforcement. These controls tend to break down when legacy systems cannot issue short-lived credentials or enforce per-request policy because static secrets and flat trust zones remain embedded in the architecture.
Common Variations and Edge Cases
Tighter Zero Trust controls often increase operational overhead, requiring organisations to balance security precision against service complexity and engineering maturity. That tradeoff becomes especially visible in hybrid estates, OT environments, and legacy applications that were never designed for continuous verification or rapid credential rotation.
Best practice is evolving on how far to push Zero Trust into resilience planning, but current guidance suggests the two should not be separated. If recovery plans assume trust is restored after failover, attackers can simply follow the workload into the backup path. If access policies are too rigid, critical workflows may fail during an incident and create self-inflicted downtime.
There are also important edge cases. Shared service accounts, break-glass access, and third-party integrations may need exceptional handling, but exceptions should be tightly monitored and time-bound. Likewise, some teams focus on network microsegmentation while leaving secret hygiene weak; that still allows credential replay and misuse. NHIMG research notes that 96% of organisations store secrets outside of secrets managers in vulnerable locations, which makes “Zero Trust” largely symbolic if those secrets are never constrained or rotated. The practical answer is not more slogans, but verified identity, constrained privilege, and recovery paths that assume the attacker may still be inside.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | Zero Trust depends on identity-aware access decisions and continual enforcement. |
| NIST Zero Trust (SP 800-207) | This question centers on continuous verification and explicit trust decisions. | |
| NIST SP 800-53 Rev 5 | AC-2 | Account lifecycle controls matter for service accounts and privileged access. |
Make access conditional on verified identity, context, and policy at each use.
