What breaks when certification workflows are not tied to live data?

Why This Matters for Security Teams

Certification workflows only work when the evidence being reviewed matches the live system of record. If access recertification is based on exported lists, stale screenshots, or manually reconciled spreadsheets, reviewers are certifying yesterday’s state, not today’s access. That undermines audit defensibility and creates blind spots around dormant accounts, over-privileged NHIs, and unexpected privilege drift.

NHI Mgmt Group notes that only 5.7% of organisations have full visibility into their service accounts, which helps explain why certification often becomes a paper exercise instead of an operational control. The risk is especially acute for secrets and service accounts because their permissions change quietly and at machine speed. Guidance in the NIST Cybersecurity Framework 2.0 emphasises continuous governance and traceability, not periodic guesswork.

Practitioners also see this problem in real incidents tied to weak NHI visibility, including the Ultimate Guide to NHIs — Key Research and Survey Results and the Sisense breach. In practice, many security teams encounter drift only after access has already been abused, rather than through intentional review.

How It Works in Practice

A live-data certification workflow pulls current entitlements directly from authoritative sources such as IAM, PAM, cloud control planes, CI/CD platforms, and secrets managers. That means the reviewer sees the actual identity, its current roles, active keys, last-seen activity, and any temporary elevation already in force. The workflow should also capture change timestamps so an approver can tell whether access was granted, modified, or revoked after the review began.

For NHIs, this is more than a convenience. Static exports cannot reliably reflect short-lived tokens, rotated keys, or service accounts created by automation. A stronger pattern is to bind certification to the source of truth and require approvals to be evaluated against live attributes, similar to how NIST Cybersecurity Framework 2.0 treats governance as an active control, not a periodic report. Where organisations are mature, the workflow also triggers remediation automatically: revoke stale access, open a ticket for exceptions, or force re-attestation when the underlying risk score changes.

• Use authoritative connectors, not exported files, for users, service accounts, tokens, and certificates.
• Show reviewer context such as owner, last use, privilege level, and expiration date.
• Block certification on records that cannot be reconciled to live data.
• Record who approved, what changed, and when the source data was last refreshed.

This approach is especially important when secrets live outside vaults or NHIs have broad privilege, because the underlying state can change faster than the review cadence. The Ultimate Guide to NHIs — What are Non-Human Identities provides the broader governance context. These controls tend to break down in highly distributed environments where identity data is fragmented across cloud accounts, SaaS tools, and CI/CD pipelines because no single source can be trusted without reconciliation.

Common Variations and Edge Cases

Tighter certification controls often increase operational overhead, requiring organisations to balance audit confidence against workflow friction. That tradeoff becomes visible in environments with many ephemeral identities, rapid deployment cycles, or delegated administration, where forcing manual attestations can slow release velocity and create review fatigue.

There is no universal standard for every certification scenario yet, but current guidance suggests treating high-risk NHIs differently from low-risk human accounts. For example, short-lived deployment identities may need automated revalidation based on runtime telemetry rather than quarterly manager review, while privileged service accounts may require dual approval and immediate revocation on non-response. The right model depends on whether the system can prove freshness, ownership, and revocation status at the moment of certification.

Edge cases also appear when data sources disagree. If the IAM directory says one thing and the cloud provider says another, the workflow should flag the record as unresolved rather than allowing a false attestation. That is where live reconciliation matters most, because a certification that cannot resolve drift is not really a certification. NHI Mgmt Group’s research shows how widespread the underlying weakness is: 79% of organisations have experienced secrets leaks, with 77% of those incidents resulting in tangible damage. In environments with high automation and frequent secret rotation, certification breaks down when reviewers cannot reliably tell whether the evidence is current or merely cached.

Related resources from NHI Mgmt Group

• What breaks when compliance monitoring is disconnected from data lineage?
• What breaks when TXT records are unmanaged in identity workflows?
• What breaks when DNS access is not tied to ownership and offboarding?
• What breaks when Office 365 identity reviews rely only on periodic certification?