Account attestation is the process of verifying that an identity still has a valid business purpose, owner, and access scope. For OT, it must cover local accounts, service accounts, and AI-related identities that may not sit neatly in a central directory but can still affect production systems.
What Account Attestation Is For
Account attestation is not just inventory. It is a governance check on whether each account still has a business owner, a valid purpose, and a justified access scope, so the organisation can distinguish active need from legacy entitlement.
That matters because accounts tend to outlive the project, person, or system that created them. Attestation creates an explicit decision point: keep, reduce, convert, or remove the account based on current business use.
How Account Attestation Works in Practice
Most attestation programmes start by grouping accounts by owner, system, application, or business process, then asking a responsible approver to confirm whether the account is still needed and whether its access remains appropriate.
For higher-risk environments, the review should go beyond the directory record and examine whether the account is actually used, whether the owner is still accountable, and whether the privilege level matches the task it supports. The same logic applies to service account, local accounts, and other accounts that may sit outside a central identity workflow.
In practice, the strength of attestation is that it turns access review into an ownership decision. A review is only useful when the approver can validate purpose, accept responsibility for exceptions, and trigger remediation when the answer is no longer clear.
Why Account Attestation Matters for Security and Operations
Unreviewed accounts become a source of stale access, orphaned privilege, and hidden dependencies. Over time, those accounts can preserve access long after the original need has disappeared, which increases the blast radius of misuse, compromise, or simple administrative error.
Account attestation also reduces ambiguity during audits, incident response, and system change. When ownership and business purpose are current, it is easier to tell whether an account is legitimate, overdue for removal, or carrying more access than it should.
In operational settings, the biggest value is not just cleanup, it is confidence. A well-run attestation process gives security, platform, and application owners a shared view of which accounts still matter to production.
What Good Attestation Should Cover
A strong attestation process should cover the account owner, business purpose, access scope, and review cadence, but it should also reflect the type of account being reviewed. Human user accounts, shared accounts, service accounts, and OT-adjacent accounts often need different questions and different approval paths.
Where the account supports production or privileged activity, reviewers should confirm not only that the account exists for a reason, but that the reason is still current and the access is still minimal. The review should also be able to identify accounts that are technically valid but operationally obsolete.
For environments with AI-related identities or other non-standard account types, attestation needs to capture who owns the relationship, what system or workflow depends on it, and whether the access is still aligned to the intended control boundary.
Risk and Threat Considerations
Accounts that are never re-attested tend to accumulate excess privilege, lose clear ownership, and remain active after their legitimate use has ended. That creates a durable exposure path for misuse, accidental overreach, and attacker persistence if an account is abused or compromised.
Failure mechanism: stale approvals, orphaned ownership, and incomplete visibility allow access to remain in place even after the business justification has disappeared.
Impact: organisations can end up with hidden privileged access, harder incident scoping, weaker audit evidence, and a larger attack surface across both standard IT and operational environments.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Defines account lifecycle review and disabling for accounts no longer needed. |
| IA-5 — Authenticator Management | Covers management of account credentials that attestation often exposes as stale or overused. | |
| AC-6 — Least Privilege | Attestation is used to verify access scope remains no broader than required. | |
| Recommendation — Review account ownership and disable accounts that no longer have a valid business need. Rotate or revoke credentials when attestation shows an account is still active but weakly justified. Reduce privileges that exceed the current business purpose of the account. | ||
| CIS Controls v8 | CIS-5 — Account Management | Directly addresses maintaining and reviewing account inventory and access need. |
| Recommendation — Maintain account inventory and remove accounts that are no longer authorized or needed. | ||
| NIST CSF 2.0 | ID.AM-02 — Assets are inventoried | Attestation depends on knowing which accounts and identity-bearing assets exist. |
| PR.AA-05 — Access Permissions Management | Attestation validates whether access permissions remain appropriate over time. | |
| Recommendation — Keep account inventories current so attestation reviews cover the full population. Revalidate access permissions and remove entitlements that no longer match the approved need. | ||
Practitioner Guidance
Why practitioners should care: account attestation works best when it is treated as an ownership decision, not a checkbox exercise. The reviewer must be able to say who needs the account, why it exists, and what changes if it is removed or reduced.
What to watch for: if a reviewer cannot explain the account’s current purpose, the account should usually be escalated for deeper validation rather than rubber-stamped. That is especially important for privileged, shared, service, and production-linked accounts.
Practitioner takeaway: the best attestation programmes remove uncertainty, they do not merely record it.