Recertification should be based on privilege, business criticality, dependency changes and credential exposure, not on a fixed calendar alone. High-risk identities that move money, change data or touch production systems need more frequent review than low-risk automation.
How to choose a recertification trigger for service accounts and bots
Recertification works best when it follows risk signals, not a fixed anniversary date. The useful question is whether the identity still has the same purpose, privilege, owner and dependency profile as when it was approved. That means reviews should intensify when the account can affect production, money movement, sensitive data or external integrations.
For service account, the trigger often shifts when the workload changes, the application is replatformed, a dependency is removed, or the credential model changes. For bots, the trigger should also include process drift, change in business ownership, and any move from low-impact automation to action that can commit transactions or modify records.
One practical anchor is whether the identity still needs the access it has today. If the answer is unclear, or if the account is difficult to explain in business terms, recertification should happen sooner and include an ownership check. NHIMG’s NHI Ownership and Accountability Guide is useful here because orphaned or weakly owned identities are the ones most likely to escape periodic review.
Which changes should force an earlier review?
Any change that can alter blast radius should move the account into the next recertification cycle. That includes expanded permissions, a new upstream data source, a different target environment, a new integration partner, or a credential that has been copied into a second system. A bot that starts as a reporting helper can become a control point for approvals, payments or provisioning, which changes the review threshold materially.
Exposure also matters. If a secret has been copied, shared, stored outside a vault, or used in a long-lived form, the account should be revalidated even if the permission set has not changed. The underlying issue is that credential exposure changes trust in the identity itself, not just its password or token state. NHIMG’s Guide to NHI Rotation Challenges is a good companion resource for understanding why rotation and recertification often need to be coordinated.
Business criticality should also pull the review forward. Accounts tied to production, regulated data, financial posting, or customer-facing workflows deserve more frequent attestation than utilities that only run non-sensitive internal tasks. The recertification interval should shorten as the identity’s ability to cause operational or regulatory impact increases.
What good recertification looks like in practice
Good recertification is evidence-based, not just a spreadsheet approval. The reviewer should be able to answer who owns the identity, what workload or bot process depends on it, where it authenticates, what permissions it uses, and whether those permissions are still necessary. If those answers cannot be produced quickly, the identity is already overdue for deeper review.
At scale, organisations should pair recertification with inventory and telemetry so the review cycle is driven by change, not memory. Accounts that are active every day but rarely changed may still deserve regular review, while dormant accounts with standing access often deserve immediate attention because inactivity can hide forgotten privilege. NHIMG’s Service Account Security Guide and Top 10 NHI Issues both reinforce the operational point that visibility, ownership and privilege review belong together.
For more technical environments, especially cloud and Kubernetes, review cadence should also consider how quickly workload identity changes, how often tokens are issued, and whether the identity is bound to a deployment artifact or a living runtime. NHIMG’s Kubernetes NHI Security Guide and Cloud Workload Identity Guide help frame that decision around runtime trust, not just calendar timing.
Risk and Threat Considerations
Service accounts and bots often accumulate access quietly, especially when they are reused across projects, environments or teams. The risk is not only excess privilege, but stale privilege: an identity can remain active long after its business purpose has changed, giving attackers or insiders a durable path to production systems and sensitive data.
Failure mechanism: When recertification is calendar-only, organisations miss trigger events such as scope expansion, dependency changes, secret leakage or ownership drift. That allows overprivileged or orphaned identities to persist with no fresh business justification.
Impact: The result can be unauthorized changes, data exposure, fraudulent workflow execution, lateral movement or long-lived access that survives normal personnel and application changes.
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 addresses the attack surface, NIST SP 800-53 Rev 5 sets the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Service account and bot recertification is account lifecycle governance. |
| IA-5 — Authenticator Management | Credential exposure and rotation are central to recertifying non-human accounts. | |
| AC-6 — Least Privilege | Recertification should confirm that service accounts retain only needed access. | |
| Recommendation — Review account necessity, ownership and status on a risk-based schedule. Rotate or retire exposed authenticators before re-approving continued use. Revalidate and remove any permissions no longer required for the workload. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | Recertification is part of maintaining accurate identity ownership and status. |
| A.5.18 — Access rights | Periodic review of access rights is directly implicated when recertifying privileged automation. | |
| Recommendation — Maintain a current register of service and bot identities with assigned owners. Reassess access rights after business, dependency or role changes. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Stale service accounts and bots can persist after their business purpose ends. |
| NHI-05 — Overprivileged NHI | Risk-based recertification is meant to catch excess privilege before it persists. | |
| NHI-07 — Long-Lived Secrets | Credential exposure and aging secrets should trigger earlier review for service accounts. | |
| Recommendation — Retire identities promptly when the workload or bot is no longer needed. Reduce privileges whenever the identity’s current function no longer justifies them. Shorten secret lifetimes and recertify when credentials are exposed or reused. | ||
Practitioner Guidance
What to prioritise: Review the highest-risk identities first, meaning those that can write to production, move funds, access regulated data, or authenticate to third-party systems with broad trust. Low-risk automation can stay on a slower cadence only when ownership, scope and secret hygiene are stable.
What to verify: Before approving recertification, confirm the business owner, technical owner, current dependency, current privilege set and secret handling method. If any one of those is unknown, treat the identity as a candidate for immediate remediation rather than routine renewal.
Decision rule: If the identity can still do something material and the team cannot explain why that access remains necessary, shorten the recertification interval and pair the review with privilege reduction or credential rotation.
Practitioner takeaway: The best recertification programmes are event-driven first and calendar-driven second, because the real risk comes from changes in privilege, purpose and exposure, not from the passage of time alone.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org