Because they check status on a schedule while machine access changes continuously. A review can say an entitlement existed at one point, but it cannot show whether the identity is still in use, what depends on it, or whether its scope has drifted since the last cycle.
Why schedule-based access reviews miss the real state of machine access
Periodic reviews only sample a moving system. Machine identities can change role, scope, environment, dependency set, or execution path between review dates, so a clean attestation can still leave stale, unused, or overextended access in place. The problem is not review intent, but the mismatch between a snapshot process and continuously changing machine behaviour.
A second gap is that reviews often validate entitlement existence, not operational necessity. A service account may still be approved while the underlying workload has been replaced, a token path has changed, or the identity now supports more systems than the reviewer can see. For machine access, the important questions are whether the identity is still used, what it depends on, and whether its permissions still match current runtime behaviour.
What false confidence looks like in practice
The most common failure mode is treating “no exceptions found” as evidence of good control health. That conclusion is weak when the review process does not test for active usage, ownership, dependency mapping, credential age, or privilege drift. A machine identity can pass review and still be functionally invisible until an outage, compromise, or rotation event exposes the gap.
This is why lifecycle matters more than approval alone. If review outcomes are not tied to provisioning, rotation, offboarding, and runtime observation, they can preserve access that no longer has a valid business or technical purpose. NHIMG’s NHI Lifecycle Management Guide is a useful reference point for the controls that sit around the review cycle, not just inside it.
Periodic review also struggles with shared or embedded credentials, where one entitlement can support multiple applications or environments. In those cases, the review may show one approved owner and one approved scope while hiding downstream reuse. That is exactly where a snapshot creates false comfort: the record looks current, but the actual access path may already have drifted.
Why the safer model is continuous context, not calendar approval
For machine identities, the stronger control question is not “was this reviewed?” but “can we prove it is still needed and still bounded?” That requires runtime signals, ownership, dependency visibility, and a rotation or expiry model that reduces the time a stale entitlement can survive. Access Reviews and Certification Guide and NHI Ownership and Accountability Guide together reflect the two missing pieces: review quality and accountable ownership.
When machine identities are in scope, a good control design uses review as one input, not the control outcome. The control outcome is whether the identity has a current owner, a current purpose, a current dependency map, and a current limit on where and how it can authenticate. Without those four signals, the review is mostly administrative.
In practice, the strongest programs shorten the gap between verification points. They combine inventory, expiry, rotation, and activity checks so that privilege does not rely on a quarterly memory test. That is the difference between proving a record exists and proving the access is still justified.
Risk and Threat Considerations
False confidence becomes a security issue when stale machine access stays valid long enough to be abused. Attackers favour credentials and service accounts that are rarely inspected, poorly owned, or widely reused, because those identities often carry durable access and minimal human scrutiny. A periodic review can miss the period of exposure entirely if compromise, reuse, or overextension happens after the last attestation.
Failure mechanism: The review checks entitlement status at a point in time, but does not detect whether the identity is dormant, reused, overprivileged, or already dependent on a changed workload or secret path. That leaves a control gap between approval and actual runtime necessity.
Impact: Stale or excessive machine access can persist unnoticed, increasing the blast radius of compromise, enabling lateral movement, and delaying safe rotation or removal until an incident forces discovery.
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 and risk surface, while NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Stale machine access after role or workload change is an offboarding gap. |
| NHI-05 — Overprivileged NHI | Reviews can miss excess permissions that survive beyond current need. | |
| NHI-07 — Long-Lived Secrets | Long-lived credentials create false confidence between review cycles. | |
| Recommendation — Revoke machine access when the workload or owner changes. Trim machine privileges to the minimum current runtime scope. Reduce credential lifetime so stale access expires quickly. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Periodic review is part of governing accounts, owners, and lifecycle. |
| IA-5 — Authenticator Management | Machine access often persists through keys, tokens, and certificates. | |
| AC-6 — Least Privilege | False confidence arises when review approves more access than needed. | |
| Recommendation — Tie machine account reviews to ownership, status, and removal. Track and rotate machine authenticators on a defined lifecycle. Constrain machine identities to the smallest required permission set. | ||
| NIST CSF 2.0 | PR.AA-05 — Assets are managed, including identities and access rights | The subject is about managing access rights for machine identities. |
| ID.AM-01 — Physical devices and systems are inventoried | Inventory and visibility are needed to know which machine identities exist. | |
| Recommendation — Maintain current inventory and access ownership for machine identities. Inventory machine identities and their dependencies before certifying access. | ||
| CIS Controls v8 | CIS-5 — Account Management | Periodic review should feed account removal, not just attestation. |
| Recommendation — Continuously review and remove inactive machine accounts and credentials. | ||
Practitioner Guidance
What to verify: Treat every machine identity review as incomplete unless it answers three operational questions: is the identity actively used, who owns the dependency chain, and what has changed since the last cycle? If you cannot answer those, the review is an administrative checkpoint, not evidence that access is still appropriate.
Common mistake: Do not rely on reviewer approval alone for service accounts, API keys, tokens, or workload credentials. If the identity can authenticate without a human in the loop, pair the review with activity data, expiry, and dependency mapping so that dormant access is removed instead of merely reapproved.
Practitioner takeaway: Periodic access reviews are useful for governance, but they are a weak truth source for machine identities unless they are anchored to lifecycle, usage, and ownership evidence. The goal is not to certify yesterday’s entitlement, but to keep today’s access observable, bounded, and removable.
Related resources from NHI Mgmt Group
- How should security teams run access reviews for non-human identities?
- When do NHI access reviews create more value than a one-time cleanup?
- Why do periodic access reviews fail for high-churn machine identities?
- Why do IGA programs create false confidence when access reviews and SoD checks appear to pass?