When certification lags platform change, historical competence can be mistaken for current readiness. That creates a governance gap where people remain trusted for workflows, consoles, or recovery processes that have materially changed. Organisations should review certification relevance whenever major releases, deprecations, or operating model shifts occur.
Why This Matters for Security Teams
When certification falls behind platform change, the organisation is no longer verifying current capability. That matters because access, recovery, and administrative workflows often change faster than training or attestations. A person may still know the old console or old break-glass path, while the actual system now routes through different approvals, scoped permissions, or automation. The result is a governance gap, not just a documentation issue.
This is especially risky for NHI-heavy environments, where operational trust is tightly coupled to secrets, service accounts, and recovery processes. NHIMG research shows that 97% of NHIs carry excessive privileges and 71% are not rotated within recommended time frames, which means outdated human certification can sit alongside already fragile machine access. The Ultimate Guide to NHIs — What are Non-Human Identities provides the broader governance context, while NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls anchors the expectation that access governance must stay aligned to current operational reality.
In practice, many security teams discover the gap only after a release, outage, or audit has already exposed that the certification record no longer matches how the platform actually works.
How It Works in Practice
The practical fix is to treat certification as a living control tied to platform state, not a one-time competency event. When a major release changes console layouts, privilege boundaries, recovery steps, or NHI workflows, the relevant certification scope should be revalidated. That may mean recertifying operators, updating role descriptions, retraining approvers, or removing trust from people whose knowledge is now stale.
For NHI and agentic operations, the most important question is whether the person can still safely manage the current system state, including service account lifecycle, secret rotation, emergency access, and rollback paths. Certification should therefore be linked to specific capabilities, such as:
- Administering the current platform version and its access model
- Approving or executing JIT access for privileged workflows
- Handling secrets, tokens, and certificates in the live environment
- Using the current recovery and incident-response procedures
- Reviewing NHI posture after changes to tooling or deployment pipelines
Current guidance suggests pairing certification review with change management, so a deprecation, migration, or control-plane redesign automatically triggers reassessment. This is consistent with the lifecycle emphasis in the Ultimate Guide to NHIs — The NHI Market, where operational trust must keep pace with identity sprawl and shifting responsibility. In zero trust environments, the principle is straightforward: trust should be continually re-earned against current context, not inherited from past validation. These controls tend to break down when releases are frequent and ownership is split across platform, security, and operations teams because no single group owns recertification triggers.
Common Variations and Edge Cases
Tighter recertification often increases operational overhead, requiring organisations to balance assurance against release velocity. That tradeoff is most visible in cloud-native and agentic environments, where platform changes happen continuously and manual certification quickly becomes obsolete. Best practice is evolving, but there is no universal standard for how often every role must be recertified; the right cadence depends on change frequency, privilege level, and blast radius.
Edge cases appear when certification covers broad job families instead of specific platform duties. A person may remain qualified for general operations while no longer being safe to approve recovery actions on a redesigned control plane. Another common issue is inherited trust: teams assume that prior certification covers new automation, new consoles, or new NHI tooling, even though the control paths have changed materially. The Schneider Electric credentials breach and Sisense breach both reinforce a practical lesson: trust breaks down quickly when credentials, workflows, or platform assumptions outlive the environment they were meant to secure. For that reason, certification should be treated as a change-sensitive control, not a static HR artifact.
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 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-01 | Identity proofing and access alignment depend on current, validated competence. |
| OWASP Non-Human Identity Top 10 | NHI-01 | NHI governance weakens when operational trust and lifecycle controls drift from reality. |
| CSA MAESTRO | GOV-03 | Agentic and platform governance requires change-aware accountability and review. |
| NIST AI RMF | GOVERN | AI governance depends on ongoing accountability as systems and roles evolve. |
Map human certification to live NHI workflows and trigger review when platform changes alter control ownership.
