Why do access certification processes often fail for workloads and service accounts?

Because certification workflows were designed around people, managers, and job changes, not identities that persist independently of employment cycles. When the subject is a workload or service account, the review must be tied to technical ownership, entitlement scope, and lifecycle events instead.

Why This Matters for Security Teams

access certification is a control for proving that access still makes sense. That works reasonably well when the subject is a person with a manager, a job code, and a stable operating pattern. It breaks down for workloads and service accounts because their value lies in continuity, automation, and system-to-system trust, not employment lifecycle events. Certification teams often approve what they do not understand, then inherit the risk when ownership, purpose, and entitlement scope are missing.

NHI Management Group research highlights how common this gap is: in the Critical Gaps in Machine Identity Management report, 59% of companies said auditing machine identities is harder because of unclear ownership and limited visibility. That finding matters because certification depends on both. If a reviewer cannot identify the technical owner, expected workload behavior, or downstream dependencies, the review becomes a checkbox exercise rather than a control. Current guidance from the OWASP Non-Human Identity Top 10 and the NIST SP 800-53 Rev. 5 Security and Privacy Controls both points toward stronger identity ownership and periodic review, but the operational model must be adapted for non-human subjects.

In practice, many security teams discover the failure only after a stale service account has already retained access long after the application changed, moved, or was retired.

How It Works in Practice

For workloads and service accounts, certification should be triggered by technical lifecycle events, not calendar reminders alone. That means tying review to application ownership, deployment pipelines, infrastructure changes, secret rotation, certificate renewal, and decommissioning. The reviewer should answer a different set of questions than they would for a person: what workload owns this identity, what systems can it reach, what secrets or certificates back it, and what breaks if it is removed?

A practical review workflow usually includes four checks:

• Confirm the technical owner, not just the business sponsor.
• Validate the purpose of the account against actual runtime usage and logs.
• Review entitlements for scope creep, especially broad API, database, or administrative access.
• Require a remediation path: remove, constrain, or convert the identity to shorter-lived credentials.

This is where workload identity becomes more useful than legacy shared secrets. The SPIFFE workload identity specification describes a cryptographic identity model for workloads, which is far easier to tie to automated ownership and runtime policy than an orphaned service account password. NHI Management Group’s Ultimate Guide to NHIs – Key Challenges and Risks also notes that machine identities often outnumber human identities, so manual certification does not scale. In mature environments, certification is paired with policy enforcement, secret expiry, and workload telemetry so reviewers can validate actual use rather than rely on stale documentation. These controls tend to break down in legacy environments where shared service accounts, undocumented integrations, and manual handoffs prevent any reliable owner or usage signal.

Common Variations and Edge Cases

Tighter certification often increases operational overhead, requiring organisations to balance stronger assurance against release velocity and service availability. That tradeoff becomes visible in environments with shared credentials, embedded secrets in legacy code, or vendor-managed integrations where a clean technical owner does not exist. In those cases, best practice is evolving rather than settled, and reviewers should classify the identity by risk tier instead of pretending every subject fits the same approval template.

One common edge case is a service account that is technically “owned” by a platform team but functionally consumed by multiple product teams. Another is a workload identity created by automation and never mapped to a named system owner. For these cases, current guidance suggests shifting from annual attestation to event-driven review with enforced expiry, scoped permissions, and evidence of runtime use. The 52 NHI Breaches Analysis shows why this matters: ambiguous ownership and weak lifecycle control repeatedly appear in real incidents. The practical goal is not perfect paperwork, but a defensible answer to who owns it, why it still exists, and what automated control will remove it when the workload changes.

Related resources from NHI Mgmt Group

• What problem does ownership attribution solve for service accounts and API keys?
• When do service accounts become a higher risk than ordinary user accounts?
• How should security teams govern Active Directory service accounts?
• Why do APIs and service accounts often expand unauthorized access risk?