They should verify that recertification updates the underlying entitlement state, not just the approval record. The control only works if revoked access is actually removed from connected systems, service accounts, and delegated admin paths. Without that reconciliation, certification becomes documentation rather than enforcement.
Why This Matters for Security Teams
ServiceNow recertification is often treated as a governance checkpoint, but the real security question is whether it changes the actual access state anywhere outside the ticketing workflow. If a reviewer clicks approve or revoke and the entitlement remains active in a connected application, a service account, or a delegated admin path, the organisation has only documented intent. That gap is especially dangerous for non-human identities, where access tends to be broad, persistent, and difficult to trace. NHI Mgmt Group reports that only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs — What are Non-Human Identities, which helps explain why recertification can look complete while access continues unnoticed.For security teams, the issue is not whether the review happened, but whether downstream enforcement followed. That distinction matters under NIST SP 800-207 Zero Trust Architecture, where access decisions are expected to be continuously validated rather than assumed durable after a single approval cycle. In practice, many security teams encounter stale access only after an audit, an incident, or a third-party review exposes that recertification never reached the target system.
How It Works in Practice
A reliable recertification process should be tested as an end-to-end control, not a workflow alone. Start by tracing one entitlement from the ServiceNow record to the live permission in the connected system, then verify what happens when the reviewer selects revoke, approve, or no action. The key question is whether the platform updates the underlying identity store, the application entitlement, and any replicated or delegated path that can still use the access.That verification usually needs to cover three layers:
- Primary entitlement state in the source system, including account disablement or role removal.
- Downstream references, such as service accounts, API keys, group memberships, and scheduled jobs.
- Exception paths, including delegated administration, cached access, and manually managed accounts.
For NHI-heavy environments, the strongest signal is reconciliation. If a review removes access in ServiceNow but the service principal still authenticates, the control has failed operationally. This is where the Sisense breach is a useful cautionary example: governance records mean little if the credentials or tokens that actually enable access are not retired. Current guidance suggests pairing recertification with automated verification, log-based proof of revocation, and periodic spot checks against actual entitlements.
Teams should also confirm whether the workflow is bi-directional. Some integrations create tickets, but do not enforce removal when the target system rejects the change or when sync fails. In that case, the safest design is to require confirmation from the authoritative identity source before marking recertification complete. These controls tend to break down when entitlement ownership is fragmented across SaaS apps, IAM directories, and custom admin tooling because no single system can prove revocation end to end.
Common Variations and Edge Cases
Tighter recertification controls often increase operational overhead, requiring organisations to balance stronger enforcement against review fatigue and integration complexity. That tradeoff becomes sharper when applications are managed by different teams or when legacy platforms do not expose clean revoke APIs.There is no universal standard for this yet, but best practice is evolving toward evidence-based recertification. That means requiring proof that access changed, not just that a reviewer signed off. In some environments, especially where shared service accounts or delegated admin roles are unavoidable, the review may need compensating controls such as separate monitoring, short-lived credentials, or manual attestation plus technical confirmation.
One useful benchmark is whether the organisation can answer, for each revocation, what happened to the identity, what happened to the credential, and what happened to the downstream session. NHI Mgmt Group’s Ultimate Guide to NHIs — What are Non-Human Identities notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is why recertification must be tied to actual deprovisioning rather than paperwork. Where systems cannot reconcile automatically, the control should be treated as partial until a downstream verification step confirms removal.
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 address the attack and risk surface, while NIST CSF 2.0 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 | Focuses on lifecycle revocation, which recertification must actually trigger. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions must be managed and removed when no longer authorized. |
| NIST Zero Trust (SP 800-207) | PR.AC-5 | Zero Trust requires continuous enforcement, not one-time approval artifacts. |
Require runtime validation that revoked access cannot still authenticate or inherit privilege.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 22, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
