What breaks when organisations rely on attestation alone for machine identities?

Attestation breaks because it asks someone to approve access they may not understand, based on a schedule that does not match machine identity lifecycles. The result is queue clearing rather than risk review. Access can remain in place for years even when it is unused, unnecessary, or inconsistent with how the identity actually behaves.

Why Attestation Alone Fails for Machine Identity Governance

Attestation is useful for proving a machine identity existed at a point in time, but it is a weak basis for ongoing access decisions. Machine identities change faster than review cycles, credentials are often reused across services, and the original business justification can disappear without any visible signal. That gap is exactly why NHI Mgmt Group’s Ultimate Guide to NHIs reports that only 5.7% of organisations have full visibility into their service accounts and that 71% of NHIs are not rotated on time.

The practical failure is not technical proof, but governance drift. An attestation can say “this identity looked legitimate when it was approved,” while remaining silent on whether it still needs access, still behaves as expected, or still belongs in the environment. That is why attestation should be treated as one input to a broader control set, not the control itself. Current guidance from NIST SP 800-53 Rev. 5 Security and Privacy Controls still expects access to be reviewed, constrained, and removed when no longer required.

In practice, many security teams discover stale machine access only after token leakage, service compromise, or an auditor asks why a dormant identity still has production reach.

How It Should Work in Practice

Attestation works best when it supports, rather than replaces, continuous identity governance. The core question is not “was this identity approved?” but “does this identity still need this access, under these conditions, right now?” For machine identities, that usually means pairing inventory, ownership, and lifecycle checks with runtime authorization and short-lived credentials. Instead of relying on a periodic sign-off, teams should use workload identity, secret rotation, and policy enforcement that can respond to changing context.

Operationally, that means four things:

• Track every non-human identity with an owner, purpose, and expiry date.
• Use CISA-style least-privilege and lifecycle thinking so dormant identities can be removed quickly.
• Issue short-lived credentials and revoke them automatically when the workload ends or changes.
• Validate access against current policy, not just historical approval, using controls that can reflect environment, workload, and risk.

This is why runtime visibility matters. Research from JetBrains GitHub plugin token exposure and Hard-Coded Secrets in VSCode Extensions shows how quickly machine credential become exposed once they are embedded in tools, code, or automation paths. A stronger model uses SPIFFE for workload identity and evaluates access through policy at request time, which is much harder for stale approvals to subvert.

These controls tend to break down in large legacy environments with shared service accounts, poor ownership records, and no dependable way to link a credential back to a specific workload.

Where the Attestation Model Breaks Down

Tighter attestation often increases administrative overhead, requiring organisations to balance audit convenience against identity accuracy. That tradeoff is real, especially where app teams want a simple approval queue and security teams want revocation precision. Current guidance suggests treating attestation as a checkpoint for governance, not as evidence that access remains necessary.

The biggest edge case is shared or embedded credentials. If multiple services use the same key, one attestation cannot prove which workload still needs it. Another common failure mode is long-lived automation in CI/CD, where the identity may be “approved” once and then silently persist across releases, forks, or environment changes. In those cases, periodic review tends to lag behind actual usage. NHI Management Group’s research notes that 96% of organisations store secrets outside secrets managers in vulnerable locations, which makes static attestation even less meaningful because the credential itself may already be out of band.

There is no universal standard for this yet, but the direction of travel is clear: organisations should move toward continuous validation, expiry-aware credentials, and explicit offboarding. Where attestation still has value is in proving who accepted responsibility for an identity at a point in time. Where it fails is assuming that approval can substitute for ongoing control.

Related resources from NHI Mgmt Group

• How can organisations reduce the blast radius of compromised agent identities?
• What breaks when organisations rely on MFA alone for digital interactions?
• What breaks when organisations rely on spreadsheets for machine identity management?
• What breaks when healthcare organisations rely on RBAC alone?