Only when the access pattern is well understood, the metadata is complete, and the approval threshold is explicit and auditable. Automation is not a substitute for governance maturity. If the programme cannot explain why an item was approved, it should not be approved automatically.
Why This Matters for Security Teams
Certification automation can reduce review fatigue, but only when the underlying identity data is trustworthy and the access model is predictable. For NHI programmes, the real risk is not just excess privilege, but approving stale or opaque access at machine speed. NHI Mgmt Group notes that 97% of NHIs carry excessive privileges and only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs — What are Non-Human Identities.
That is why certification automation should be treated as a control accelerator, not a substitute for access governance. If approvals are based on incomplete metadata, unclear ownership, or vague business justification, the automation will simply make bad decisions faster. NIST SP 800-53 Rev 5 Security and Privacy Controls expects organisations to define access review and accountability processes, which means the review model has to be explainable before it can be automated. In practice, many security teams discover that automation was validating assumptions, not access, only after a dormant credential or over-privileged service account has already been certified repeatedly.
How It Works in Practice
The practical question is whether the certification decision can be made from objective, complete, and auditable signals. If the answer is yes, automation can handle the first pass and route only exceptions to humans. If the answer is no, manual review remains the safer control because the reviewer is being asked to interpret context, not just confirm a record.
Good candidates for automation usually have:
- clear ownership mapped to a named system or team
- stable entitlements with low behavioural variance
- explicit approval thresholds, such as privilege tier, data sensitivity, or environment
- complete metadata, including purpose, expiry, and last-use evidence
- reliable logging that can support later audit or challenge
For example, a short-lived build token with a defined scope and automated expiry is often suitable for rule-driven certification. By contrast, a standing API key used across multiple pipelines, or a service account with broad lateral movement potential, usually needs manual scrutiny. Current guidance aligns with NIST SP 800-53 Rev 5 Security and Privacy Controls on accountability and review, while the NHI lifecycle view in Ultimate Guide to NHIs — What are Non-Human Identities highlights why visibility and rotation discipline must be in place before automation can be trusted.
Automation also works best when it is scoped to certification, not adjudication. That means the system can pre-populate evidence, compare against policy, and flag deviations, but the approval logic still has to be understandable to auditors and operations staff. These controls tend to break down when ownership is inherited through nested groups or when entitlements are so dynamic that the metadata cannot reliably describe what the identity is actually allowed to do.
Common Variations and Edge Cases
Tighter automation often increases governance risk if it outruns data quality, so teams have to balance efficiency against explainability. That tradeoff becomes more visible in high-change environments, where the identity state shifts faster than the certification cadence.
There is no universal standard for when a certification rule is “good enough” to automate. Current guidance suggests a tiered model: automate low-risk, highly structured recertifications; require human approval for privileged, third-party, or exception-based access; and force manual review whenever the system cannot justify the decision with evidence. This is especially important for NHIs exposed to multiple business units, because access may look legitimate in one workflow and dangerous in another.
Two common edge cases deserve special handling. First, break-glass or emergency access should usually be auto-expired but manually reviewed after the event. Second, service accounts with ephemeral credentials may be safe to certify automatically only if the issuing process, scope, and revocation path are already controlled. The broader NHI control challenge described in the Sisense breach shows how quickly access assumptions can fail when secrets, ownership, and exposure are not tightly governed. Automation is appropriate when it can enforce a policy; it is not appropriate when it must invent one.
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, NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Automation depends on accurate NHI lifecycle and privilege data. |
| NIST CSF 2.0 | PR.AC-1 | Access control decisions need clear, auditable authorization logic. |
| NIST AI RMF | GOVERN | AI governance principles apply to automated approval decisions and accountability. |
| NIST Zero Trust (SP 800-207) | 5.2 | Zero Trust requires continuously evaluated access, not blind trust in stale approvals. |
| CSA MAESTRO | GOV-02 | Agentic governance emphasises controlled decision boundaries and escalation handling. |
Automate recertification only after NHI inventory, ownership, and expiry data are continuously verified.
