Assigning an owner to every service account, API key and OAuth app is only half the job: owners leave, applications move teams and the ownership record quietly goes stale unless someone is made to confirm it. An ownership attestation campaign is a scheduled, evidence-producing exercise in which the named owner of each non-human identity (NHI) confirms that they still own it, that it is still needed and that its access is still right, or hands it on. This guide covers how to scope, design, run and measure those campaigns, how to handle the answers (including silence), and how to tie the results to offboarding and least privilege. It is written for IAM, IGA and cloud security teams who already have an NHI inventory and owner fields, and want those fields to stay true. For defining what an owner is and finding owners in the first place, see the NHI Ownership Guide.
Key takeaways
- Attestation keeps ownership true over time. It turns an owner field that was correct on the day it was set into one that is re-confirmed on a cycle, as OWASP recommends when it says to periodically recertify NHIs to confirm they are in use, needed and have valid owners.
- Ask four questions, not one. Do you own it, is it still needed, is its access still right, and is its credential handled correctly. A bare "yes, mine" is not an attestation.
- Silence must have a consequence. Decide in advance what happens to unanswered items: escalate, then reduce privilege or disable, with a tested rollback. A campaign where non-response means "keep" certifies nothing.
- Pre-fill evidence so owners can decide quickly. Last-used dates, unused permissions and credential age from the platforms themselves cut rubber-stamping more than any reminder email.
- Combine a quarterly baseline with event triggers. CIS Safeguard 5.5 sets quarterly as the minimum for service account reviews; owner departures, dormancy and risk changes should trigger an attestation in between.
What an ownership attestation campaign is
An attestation campaign is a time-boxed review in which a defined set of NHIs is sent to their recorded owners, each owner records a decision per identity, and the decisions are applied and kept as evidence. It is a specialised form of the access certification described in the Access Reviews Guide, but the primary subject is different: a human access review asks "should this person have this access", while an NHI ownership attestation first asks "is this still yours, and should this identity exist at all".
That ordering matters because the main failure OWASP describes in NHI1:2025 Improper Offboarding is not excess privilege on an active identity but identities that outlive their purpose: stale or dormant NHIs whose application was retired, orphaned NHIs whose owner left with no successor, and credentials still held by people who have left. An attestation that only reviews permissions on identities nobody owns will not find those.
| Exercise | Primary question | Reviewer | Typical output |
|---|---|---|---|
| Ownership assignment (one-off) | Who should own this? | Identity or platform team, using discovery signals | Owner and backup owner recorded |
| Ownership attestation campaign | Is this still yours and still needed? | Recorded technical or business owner | Confirm, transfer, decommission or flag, with evidence |
| Entitlement or privilege review | Is this access still right? | Resource owner or owner of the NHI | Keep, reduce or remove specific permissions |
| Offboarding review | What did the leaver own or hold? | Leaver's manager and backup owner | Transfer, rotate or decommission |
A mature programme folds the second and third into one campaign item, so the owner sees the identity, its purpose and its unused access on one screen.
Scoping: which NHIs, which owners, how often
Scope by identity type and by risk, not by platform alone. A campaign that covers only Active Directory service accounts misses cloud roles, OAuth grants and CI/CD tokens, where most of the growth is.
Identity types to include
- Directory service accounts: Active Directory, LDAP and gMSA accounts. See the Service Account Security Guide.
- Cloud identities: AWS IAM roles and IAM users with access keys, Microsoft Entra service principals and app registrations, Google Cloud service accounts and their keys.
- SaaS integrations and OAuth apps: third-party apps with tenant-wide consent, integration users and bot accounts. See the SaaS and OAuth App Governance Guide.
- Static secrets: API keys, personal access tokens used by automation, signing keys and certificates where the key holder is the accountable party. See the API Key Management Guide.
- AI agents: agent identities and the delegated credentials they hold. See the Identity Governance for AI Agents Guide.
Cadence by tier
| Tier | Examples | Baseline cadence | Event triggers |
|---|---|---|---|
| Tier 1: privileged or sensitive | Cloud admin roles, directory-wide app permissions, signing keys, CI/CD deploy credentials | Quarterly at least; monthly where tooling makes it cheap | Owner leaves or moves, privilege added, credential leak alert, risk score crosses threshold |
| Tier 2: production, scoped | Application service accounts, scoped API keys, single-resource roles | Quarterly (CIS Safeguard 5.5 minimum for service accounts) | Owner leaves, identity dormant past threshold |
| Tier 3: non-production and low impact | Test tenant apps, sandbox keys, read-only reporting integrations | Quarterly or semi-annual, batched by team | Dormancy, owner leaves |
Do not treat "non-production" as automatically Tier 3. The Microsoft Midnight Blizzard breach began with a legacy test tenant account and a legacy test OAuth app that had elevated access to the corporate environment. Tier by what the identity can reach, not by where it was created. The NHI Risk Scoring Guide describes a transparent way to set tiers from privilege, exposure, age, ownership and usage.
Who attests
- Technical owner: the default attester for existence, need and credential handling, because they know what calls the identity.
- Business owner: co-attests Tier 1 items and accepts residual risk where privilege cannot be reduced.
- Backup owner: receives the item if the primary owner has left or is absent, and becomes the escalation point.
- Not the creator by default: the person who created an identity is a discovery signal, not an owner.
Designing the attestation questions
Each campaign item should present one identity and ask for an explicit decision against a small set of questions. Keep the questions fixed across campaigns so answers can be compared over time.
| Question | Evidence shown to the owner | Allowed answers | Action if answered "no" |
|---|---|---|---|
| 1. Do you (or your team) own this identity? | Recorded owner, creator from audit logs, consuming application, repository or cost centre tags | Yes / No, transfer to named person / Not ours, unknown | Transfer workflow, or route to the orphan queue |
| 2. Is it still needed, and for what? | Recorded purpose, last authentication or last used date, consuming workloads | Yes with purpose confirmed / Yes, purpose updated / No | Disable, then decommission after a hold period |
| 3. Is its access still right? | Attached roles or scopes, unused services or permissions over the review window, admin flags | Keep / Reduce (select items) / Request exception | Remediation ticket with due date, or exception with expiry |
| 4. Is its credential handled correctly? | Credential type, age, expiry, last rotation, storage location (vault or not), number of active keys | Yes / Needs rotation / Migrate to short-lived credential | Rotation ticket, or migration plan with date |
- Make "purpose" a free-text field that is required: CIS Safeguard 5.5 lists department owner, review date and purpose as the minimum inventory content, so the campaign is the natural place to keep purpose current.
- Forbid bulk "approve all" for Tier 1: allow bulk actions only for Tier 3 items with recent use and no admin rights.
- Record who answered and when: the attestation record is audit evidence for NIST SP 800-53 AC-2 (review accounts at a defined frequency) and AC-6(7) (review privileges and reassign or remove them).
Evidence to pre-fill from the platforms
Owners decide faster and more accurately when the item already shows whether the identity is used. Most platforms expose this natively.
| Platform | Native signal | What it tells the owner |
|---|---|---|
| AWS | IAM Access Analyzer unused access findings | Unused roles, unused IAM user access keys and passwords, and unused service-level and action-level permissions within the analyser's usage window |
| AWS | IAM last accessed information | Which services an identity can reach and when each was last accessed; service data covers at least the last 400 days |
| Microsoft Entra ID | Access reviews for privileged roles (PIM), with service principals in scope | Service principals holding Microsoft Entra or Azure resource roles, reviewed by selected reviewers on a set recurrence |
| Google Cloud | Service account insights and Activity Analyzer | Service accounts that have not authenticated in the past 90 days, and when a service account or key was last used |
| Google Cloud | Event Threat Detection (Security Command Center Premium) | Alerts when a dormant service account, inactive for more than 180 days, takes an action |
| Any | Secrets manager or vault metadata | Credential age, last rotation, and whether the secret is stored centrally at all |
Two cautions. First, AWS documents that last accessed data records attempts, including denied ones, so treat it as "was it called", with CloudTrail as the authority on success. Second, the Entra access review sign-in recommendations are described in terms of user sign-ins; confirm in your tenant whether recommendations appear for service principals before relying on them. Reviewing service principals in PIM reviews requires Microsoft Entra Workload ID Premium in addition to Microsoft Entra ID P2 or ID Governance.
The Cloudflare Thanksgiving breach shows why measured usage matters: one service token and three service account credentials were not rotated after the Okta support system breach because, in Cloudflare's account, they were mistakenly believed to be unused. An attestation where the owner sees real last-used data turns that belief into a checked fact.
Decisions, non-response and escalation
Define the outcome of every answer, and of no answer, before the campaign launches; the deadlines below are examples to adapt. Publish the rules in the NHI policy so owners are not surprised. See the NHI Policy Template.
| Outcome | Automatic follow-up | Deadline (example) |
|---|---|---|
| Confirmed, no changes | Next review date set; evidence stored | None |
| Confirmed, access reduced | Remediation ticket to platform team, verified by re-scan | Tier 1: 14 days; others: 30 days |
| Transferred | New owner must accept the transfer, then answers the same questions | 7 days to accept, or it escalates |
| Not needed | Disable (not delete), start hold period, then decommission | Disable within 7 days; delete after 30 to 90 days with no breakage |
| Not ours / unknown | Orphan queue, ownership discovery using signals, notice to likely team | Claim within 14 days |
| No response | Reminder, then escalation to backup owner and manager, then the non-response action | Escalate at day 7; act at campaign close |
| Exception requested | Risk acceptance by business owner, with expiry and compensating controls | Expiry no later than next campaign |
Choosing the non-response action
- Keep (no change): only acceptable in a first campaign while you measure response rates. As a standing rule it makes the campaign meaningless.
- Reduce privilege: remove admin roles or unused permissions but leave the identity working. A good default for Tier 1 items that are clearly in use.
- Disable credential or identity: appropriate for items with no recent use. Microsoft Entra PIM reviews offer "Remove access" as the "If reviewers don't respond" setting, alongside "No change", "Approve access" and "Take recommendations", and "Auto apply results to resource" applies denials automatically.
- Never auto-approve: "Approve access" on non-response produces a signed record that nobody looked at.
Google Cloud recommends disabling an unused service account before deleting it, because a disabled account can be re-enabled if it turns out to be in use. Apply the same principle on every platform: disable, watch for breakage, then delete. Exceptions belong in the process described in the Security Exceptions and Risk Acceptance Guide.
Event-driven attestations between campaigns
Quarterly cycles leave gaps of up to three months. The events below should create a single attestation item immediately, outside the campaign calendar.
- Owner leaves: OWASP NHI1 recommends that offboarding reviews all NHIs associated with departing employees, decides whether each is still needed, and transfers ownership and rotates credentials the leaver could reach. See the Joiner-Mover-Leaver Guide.
- Owner moves team: ask the mover to transfer identities belonging to the old area within a set period.
- Dormancy threshold reached: CIS Safeguard 5.3 sets 45 days of inactivity for disabling dormant accounts where supported. For NHIs that run monthly or quarterly jobs, attest at 45 days rather than disabling blindly.
- Privilege increase: a new admin role, new API scope or new tenant-wide consent should require owner confirmation of purpose.
- Leak or detection alert: a secret scanning hit or identity threat alert should require the owner to confirm rotation and need.
- Application retirement: decommissioning an application in the CMDB should open attestation items for every NHI linked to it. See the NHI Offboarding and Decommissioning Guide.
The Coupang breach illustrates the leaver gap: a former developer kept a token signing key after leaving at the end of 2024, investigators found keys held by departed employees had not been revoked or rotated, and the access ran for about seven months. A leaver-triggered attestation on keys the developer could reach would have forced a rotate-or-confirm decision on day one.
Running the campaign: a phased rollout
- Baseline the inventory. Export every in-scope NHI with owner, backup owner, purpose, tier, credential type and last-used date. Measure inventory completeness first; CIS Safeguard 5.5's assessment measures count accounts missing required elements and months since last review. See the Service Account Inventory Template.
- Fix owner data before launch. Resolve departed and blank owners using discovery signals. Launching with 30% of items routed to leavers wastes the first cycle.
- Pilot in report-only mode. Run one campaign with two or three willing teams, with non-response set to "No change" and no automatic actions. Measure completion time per item and which evidence fields owners actually used.
- Tune the item. Remove evidence fields nobody reads, add the ones owners asked for, and fix entitlement names that mean nothing to an application owner.
- Expand to all Tier 1 items with enforcement. Turn on escalation and the non-response action for Tier 1 first, where the risk justifies the disruption.
- Add Tier 2 and Tier 3, batched by team. One campaign per team per quarter is easier for owners than many small ones.
- Switch on event triggers. Leaver, mover, dormancy and privilege-increase triggers, once the campaign pipeline is reliable.
- Close the loop. Verify every revocation and disablement with a fresh scan; an unexecuted revocation is worse than none because the record says it was done.
Testing and rollback
- Dry run the actions: before enabling auto-apply, list exactly which identities the non-response action would disable, and send that list to owners as a warning.
- Disable, do not delete: keep a record of the identity's configuration, role assignments and dependent jobs so it can be re-enabled within minutes.
- Define a rollback owner: the platform team on call should be able to re-enable a disabled identity outside business hours, with the incident logged against the owner who did not respond.
Small and large organisations
| Aspect | Smaller organisation | Larger organisation |
|---|---|---|
| Tooling | Spreadsheet or ticket per team, with platform exports (Access Analyzer, Activity Analyzer) attached | IGA or NHI security platform generating items, reminders and remediation automatically |
| Cadence | One quarterly campaign covering everything | Continuous: rolling campaigns by team, plus event triggers |
| Non-response | Escalate to the CTO or head of engineering, then disable manually | Policy-driven automatic action per tier |
| Evidence | Signed export per campaign | Per-item decision log with timestamps, feeding audit and metrics |
| Main risk | Campaign lapses when one person leaves | Reviewer fatigue and rubber-stamping at volume |
Detection and measurement
Measure whether campaigns change anything, not only whether they finish.
- Ownership coverage: percentage of in-scope NHIs with a current, active owner and backup owner, by tier. Target 100% for Tier 1.
- Attestation timeliness: percentage of items answered by the owner before the deadline, and items handled by escalation or the non-response action.
- Revocation yield: identities disabled or decommissioned, and permissions removed, per campaign. A yield near zero after several cycles usually signals rubber-stamping rather than a clean estate.
- Revocation completion: percentage of "remove" and "disable" decisions verified as applied by re-scan within the deadline.
- Orphan age: median days an NHI spends without a confirmed owner, and the count of enabled identities owned by departed staff.
- Enabled dormant ratio: enabled dormant NHIs divided by all dormant NHIs, the same ratio CIS uses for Safeguard 5.3.
Monitor the campaign itself: alert on identities re-enabled after disablement without an owner decision, owners approving large batches in seconds, and new NHIs created without an owner tag. Account monitoring for atypical usage (NIST SP 800-53 AC-2(12)) is the right control for dormant identities that suddenly authenticate, and is where valid account abuse (ATT&CK T1078.004 Cloud Accounts) is caught. See the Identity Security Metrics Guide.
Framework mapping
| Framework | Reference | How attestation campaigns support it |
|---|---|---|
| NIST SP 800-53 Rev. 5 | AC-2 Account Management | Assign account managers; review accounts for compliance at a defined frequency; align account management with termination and transfer |
| NIST SP 800-53 Rev. 5 | AC-2(3) Disable Accounts | Disable accounts no longer associated with an individual or inactive for a defined period |
| NIST SP 800-53 Rev. 5 | AC-6(7) Review of User Privileges | Review privileges to validate need, and reassign or remove them |
| NIST CSF 2.0 | PR.AA-01, PR.AA-05, GV.RR-02 | Credentials for services managed by the organisation; permissions reviewed with least privilege; roles and responsibilities established |
| CIS Controls v8.1 | Safeguards 5.3 and 5.5 | Disable dormant accounts after 45 days where supported; service account inventory with owner, review date and purpose, reviewed at least quarterly |
| ISO/IEC 27001:2022 | Annex A 5.16, 5.18, 8.2 | Identity management, review of access rights, privileged access rights |
| OWASP NHI Top 10 2025 | NHI1, NHI5, NHI7 | Improper offboarding, overprivileged NHI, long-lived secrets |
Common failure patterns
- Attesting ownership but not need: owners confirm "yes, mine" for identities whose application was retired. Always ask question 2 with last-used evidence.
- Non-response treated as approval: the campaign closes at 100% complete with nothing removed. Set a non-response action that changes something.
- "Unused" by assumption: owners or reviewers declare credentials unused without data, as in the Cloudflare case above. Require platform usage evidence on every item.
- Leavers only handled at the next campaign: a departing engineer's keys stay valid for months. Trigger attestation and rotation on the leaver event, as the Coupang case shows.
- Test and legacy identities excluded: scoping out non-production leaves high-reach identities unreviewed, as in the Midnight Blizzard breach. Tier by reach.
- Revocations never executed: decisions sit in a report or a ticket queue. Verify by re-scan and report completion as a metric.
Practitioner checklist
- Record owner, backup owner, purpose, tier and next review date for every in-scope NHI type, including OAuth apps, keys and AI agents.
- Fix departed and blank owners before the first enforced campaign.
- Use the four fixed questions: ownership, need, access, credential handling.
- Pre-fill last-used, unused permission and credential age evidence from platform tooling.
- Set a quarterly minimum, more often for Tier 1, plus leaver, mover, dormancy and privilege-increase triggers.
- Publish the non-response action per tier; never auto-approve.
- Disable before delete, with a documented and tested rollback path.
- Verify every revocation by re-scan and track revocation completion.
- Track ownership coverage, timeliness, revocation yield, orphan age and enabled dormant ratio.
- Keep per-item decision logs as evidence for AC-2, AC-6(7) and CIS Safeguard 5.5.
Standards and references
- OWASP: Non-Human Identities Top 10 2025
- OWASP: NHI1:2025 Improper Offboarding
- NIST: SP 800-53 Rev. 5
- CIS: Controls Assessment Specification, Safeguard 5.5 Establish and Maintain an Inventory of Service Accounts
- Microsoft Learn: Create an access review of Azure resource and Microsoft Entra roles in PIM
- AWS: IAM Access Analyzer findings
- Google Cloud: Service accounts overview
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: NHI Ownership Guide · Top 10 NHI Risks · NHI Risk Scoring Guide · Access Review Checklist · NHI Governance Maturity Model