A programme is still design-time only when access changes depend on manual tickets, periodic reviews, or human reminders instead of live signals. Another sign is when users pass certification even though their device risk, on-call status, or contract state has changed. That mismatch shows governance and enforcement are disconnected.
When is an identity programme still only designed on paper?
A design-time-only identity programme has documented policies, approval paths, and review cycles, but those controls do not change access in real time. If access still depends on tickets, periodic recertification, or someone remembering to act, the programme is describing governance rather than enforcing it. The tell is whether live state drives decisions.
What operational signs show the gap between governance and enforcement?
The clearest sign is a mismatch between changes in risk or role and changes in privilege. If a contractor has exited, an on-call rotation has changed, or a device has fallen out of compliance, but access remains until the next review window, the identity control plane is not connected to the control objective. That is where Identity Security Programme Guide becomes useful as a programme-level reference, because the issue is usually operating model and ownership, not a missing policy.
Other signs are procedural rather than technical: reviewers approve access without seeing current context, exceptions become the normal path, and joiner-mover-leaver events are handled by humans after the fact. A mature programme should be able to revoke, reduce, or re-route access from authoritative signals, not wait for a recurring certification campaign. Where lifecycle handling is weak, NHI Lifecycle Management Guide is relevant because the same pattern appears when provisioning, rotation, and offboarding exist on paper but not in execution.
Why does design-time identity break down in practice?
The failure is usually that identity governance is treated as a project deliverable instead of an operating control. Teams define roles, policies, and review cadences, but they do not wire those rules into the systems that actually grant access, such as HR events, device posture, entitlement engines, or workflow automation. When that happens, the programme can look complete in a diagram while producing stale access in production.
This is especially visible when access decisions still rely on human memory or manual reconciliation. A user can pass certification even though their job has changed because the review only checks a static list of entitlements, not whether the entitlement is still justified by current context. For the broader identity picture, Top 10 NHI Issues is a useful companion because stale approval logic, excessive permission, and ownership gaps tend to appear first where identity states are not continuously governed.
Risk and Threat Considerations
Design-time-only identity programmes create silent exposure because access can remain valid after the business reason for it has disappeared. That increases the chance of privilege accumulation, unauthorized access, and delayed containment when an account, device, or role changes outside the review cycle.
Failure mechanism: Governance checkpoints are disconnected from authoritative state changes, so access continues until a person notices, a ticket is raised, or the next certification runs.
Impact: The organisation inherits stale privilege, larger blast radius, and weaker accountability, especially when a forgotten exception or dormant entitlement is later abused.
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 addresses the attack surface, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Identity programmes must provision, modify, and revoke access as conditions change. |
| IA-5 — Authenticator Management | Design-time-only programmes often leave credentials valid after the access need has changed. | |
| AC-6 — Least Privilege | Static access reviews fail when entitlements stay broader than current need. | |
| Recommendation — Automate account lifecycle changes and revoke access when the authoritative condition changes. Enforce credential lifecycle rules so stale authenticators are rotated or invalidated promptly. Continuously trim permissions to the minimum required for the current role and context. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity and Access Control | The question is about whether identity controls are operating dynamically, not just documented. |
| Recommendation — Connect access decisions to live identity and context signals instead of periodic manual review. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | The programme concerns whether identities and access are governed through their lifecycle. |
| Recommendation — Define and enforce identity lifecycle ownership for joiner, mover, and leaver changes. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Stale access after role or contract change is a classic sign of weak offboarding. |
| NHI-05 — Overprivileged NHI | Manual review models often leave entitlements broader than current need. | |
| NHI-07 — Long-Lived Secrets | Design-time-only governance often leaves credentials effective long after they should expire. | |
| Recommendation — Trigger immediate offboarding actions when the identity owner leaves or changes status. Continuously reduce privileges to remove unused or unjustified access paths. Rotate or expire secrets on a short, enforced lifecycle instead of relying on periodic review. | ||
Practitioner Guidance
What to verify: Check whether access can change automatically from authoritative signals such as HR status, device posture, role assignment, or contract state. If the answer is no, the programme is still dependent on manual enforcement rather than control.
What to measure: Look at the lag between a triggering event and access revocation or adjustment. Long delays, repeated exceptions, and high rates of post-review cleanup are stronger evidence of design-time only governance than any policy document.
Practitioner takeaway: The real test is not whether access is reviewed, but whether the programme can change access at the moment the underlying condition changes.