An approach that assumes failures will happen and plans for continuity anyway. It combines fallback processes, dependency mapping, and blast-radius reduction so the organisation can keep operating when controls, vendors, or identity paths do not behave as expected.
Expanded Definition
Resilience by design is a security and operating model that bakes continuity into systems before incidents occur. Rather than assuming controls, vendors, or identity paths will remain reliable, it plans for degraded modes, alternate workflows, and bounded failure. In practice, that means mapping dependencies, separating critical functions, and ensuring recovery options exist when an upstream service, authenticator, or approval chain breaks.
In cybersecurity terms, this is closely aligned with resilience engineering and the continuity intent found in NIST SP 800-53 Rev 5 Security and Privacy Controls. For NHI and agentic AI environments, the concept extends to service accounts, API keys, secrets vaults, delegated workflows, and tool-using agents that must keep operating even when a single trust path fails. Definitions vary across vendors, but the core idea is consistent: resilience is engineered up front, not improvised during outage response.
The most common misapplication is treating backup infrastructure as resilience by design, which occurs when teams add recovery tools without redesigning the dependencies and failure domains that cause the outage.
Examples and Use Cases
Implementing resilience by design rigorously often introduces extra architectural and governance overhead, requiring organisations to weigh uninterrupted service against added complexity, duplicated controls, and more frequent testing.
- A platform team separates production secrets into scoped vault partitions so a single compromised service account cannot halt every workload.
- An enterprise designs fallback authentication paths for administrators so a broken identity provider does not block emergency access.
- A DevOps pipeline keeps deployment keys short-lived and replaceable, allowing builds to continue while compromised credentials are revoked.
- An AI operations team constrains agent permissions and tool access so one malfunctioning agent cannot cascade into unrelated systems.
- NHI governance teams review dependency maps and offboarding procedures using guidance from the Ultimate Guide to NHIs alongside control expectations in NIST guidance.
In high-assurance environments, resilience by design may also mean maintaining manual override steps, alternate approval routes, or offline recovery credentials for tightly controlled break-glass scenarios.
Why It Matters for Security Teams
Security teams care about resilience by design because failures rarely stay isolated. A single expired certificate, misconfigured vault, or broken token exchange can interrupt authentication, halt automation, and expose hidden dependencies that were never tested under stress. For NHI-heavy environments, the risk is amplified: NHIs often outnumber humans by 25x to 50x in modern enterprises, and unmanaged service accounts can become the first point of failure when revocation, rotation, or vault access goes wrong.
NHIMG research shows that only 5.7% of organisations have full visibility into their service accounts, which makes recovery planning difficult before an incident and even harder during one. That is why resilience by design must include identity lifecycle controls, dependency mapping, and blast-radius reduction, not just disaster recovery documentation. It also fits Zero Trust thinking, where trust is continuously evaluated rather than assumed to hold indefinitely.
Organisations typically encounter the operational cost of poor resilience only after an outage, credential failure, or agent malfunction, at which point resilience by design becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | RC.RP-1 | Recovery planning and execution define resilience after disruptive events. |
| NIST SP 800-53 Rev 5 | CP-2 | Contingency planning supports continuity when primary controls fail. |
| NIST Zero Trust (SP 800-207) | SC-7 | Segmentation and bounded trust reduce blast radius in failure scenarios. |
| OWASP Non-Human Identity Top 10 | NHI resilience depends on lifecycle and secret handling for non-human identities. | |
| NIST AI RMF | GV.1 | Governance requires accountability for resilient AI and agentic system operation. |
Build and test recovery playbooks so critical services can resume under degraded conditions.
Related resources from NHI Mgmt Group
- What is the difference between design effectiveness and operating effectiveness in compliance audits?
- When should organisations treat an API design issue as an identity risk?
- What is the difference between ransomware resilience and backup resilience?
- What is the difference between opaque tokens and JWTs in quantum-safe API design?
