The CISO's 5-Minute NHI Audit: What to Check Before Your Next Board Meeting

Your board is going to ask about identity risk. Maybe not today. But after the next CrowdStrike-level incident makes headlines, they will — and the question will be specific: "Do we have this kind of exposure?"

The uncomfortable answer for most organizations: you don't know. Not because your team isn't competent, but because non-human identities — service accounts, API keys, machine credentials, AI agent tokens — exist almost entirely outside the governance frameworks you use for human access.

This audit checklist is designed to be run in 5 minutes. Not as a substitute for a full access review, but as a pre-board-meeting snapshot: the questions you need to be able to answer before you walk into that room.

Why NHI Audits Are Board-Level Now

Non-human identities outnumber human accounts 45:1 in the average enterprise environment. They execute every automated workflow, every CI/CD pipeline, every third-party integration. They're also the attack surface most organizations can't clearly describe.

The service account sprawl problem compounds over time: accounts get created, permissions get granted, and almost nothing gets revoked. The result is an access surface that grows faster than any cleanup process can track.

Boards are asking about this now because regulators are, too. SOC2 Type II, ISO 27001, and the SEC's cybersecurity disclosure rules all have access governance requirements that surface the same exposure. If you can't describe your NHI posture with confidence, you're not just a security risk — you're a disclosure risk.

The 5-minute audit below gives you a defensible answer for the room.

The 5-Minute CISO NHI Audit Checklist

✦ 1. Service Account Inventory: Do You Know What Exists?

What to check: Pull a count of active service accounts from your identity provider (Azure AD, Okta, AWS IAM). Compare to your last documented count.

What good looks like: You can produce a complete list within 60 seconds. The list matches (or is close to) your last documented count. Every account has an owner.

What most companies find: The count is higher than expected — often 3–10x higher than human account count. A significant percentage have no documented owner. Some exist in shadow directories that weren't included in the last audit.

Board answer you need: "We have X service accounts. Here's how we know that's accurate."

✦ 2. Credential Age: When Were These Last Rotated?

What to check: Filter your service accounts and API keys for credential age > 90 days. Then filter for > 1 year. Note the percentage.

What good looks like: Less than 20% of credentials are older than 90 days. Anything older than 1 year is flagged for review.

What most companies find: The majority of service account credentials have never been rotated. It's not uncommon to find active API keys from 4–5 years ago. The "it'll break something" fear prevents rotation.

Board answer you need: "X% of our service account credentials are within rotation policy. Here's what we're doing about the rest."

If you can't answer this, you have a credential hygiene problem — and the board should know, from you, before they find out another way.

✦ 3. Privilege Scope: How Many Have Admin or Root-Level Access?

What to check: Filter for service accounts with admin, root, or wildcard (*) permissions. What percentage of your service accounts have elevated privileges?

What good looks like: Less than 5% of service accounts have elevated privileges, and each one has a documented business justification.

What most companies find: A much higher percentage than expected. Permissions granted during initial provisioning were never reduced. CI/CD pipelines have production write access that was scoped broadly "to avoid issues." Database service accounts have DBA-level permissions when they only query one table.

Board answer you need: "We have X accounts with elevated privileges. Each is justified. Here's our least-privilege enforcement mechanism."

This is where zero standing privileges comes in — if you can say that elevated access is time-boxed and audited, the answer is materially better.

✦ 4. Orphaned Accounts: What's Still Active That Shouldn't Be?

What to check: Cross-reference service accounts against:

• Applications that have been decommissioned in the last 12 months
• Third-party integrations that were cancelled or replaced
• AI agents or bots that are no longer in production

What good looks like: Offboarding workflows exist for non-human identities. When a service gets decommissioned, its credentials are revoked within 24 hours.

What most companies find: Orphaned accounts are pervasive. The integration that was replaced 8 months ago still has an active API key with read access to customer data. The CI/CD service account for the legacy pipeline still has write access to repositories that are still in use. Nobody knows which accounts are safe to deactivate.

Board answer you need: "Our offboarding process covers machine identities. Here's how we verify accounts are revoked when services are decommissioned."

If you don't have an answer, this is a high-priority remediation item — not a "we'll get to it" item. Orphaned accounts are how attackers maintain persistence.

✦ 5. API Key Rotation Status: Are Keys Being Cycled?

What to check: Look at your primary external integrations (AWS, Stripe, Salesforce, GitHub, Snowflake, etc.). When were their API keys last rotated? Do automated rotation workflows exist?

What good looks like: Every external-facing API key has an automated rotation schedule. Rotation happens without human intervention. You can show the last rotation date for every key.

What most companies find: Rotation is manual and infrequent. Keys get generated once during initial setup and never touched unless there's an incident. Rotation is avoided because "it might break the integration." Keys in CI/CD pipelines are hardcoded in environment variables that haven't been updated in years.

Board answer you need: "API keys for our critical integrations are rotated on X schedule. Rotation is automated for Y systems, manual for Z (with timeline to automate)."

✦ 6. Compliance Gap Analysis: What Can You Actually Demonstrate?

What to check: For each NHI compliance requirement relevant to you (SOC2 CC6.1, ISO 27001 A.9.2, NIST SP 800-53 AC-2), can you produce evidence of:

• Access review documentation for non-human accounts?
• Least-privilege enforcement for machine identities?
• Automated monitoring for anomalous service account behavior?

What good looks like: You can produce audit-ready evidence within 24 hours for any of these requirements.

What most companies find: NHI accounts fall outside the scope of human-focused access reviews. The quarterly access review doesn't cover service accounts. When auditors ask for NHI-specific evidence, the answer is a spreadsheet that was manually assembled the week before the audit.

Board answer you need: "Our access review process covers non-human identities. Here's the evidence documentation we'd produce for an audit."

This connects directly to what automated access reviews look like for SOC2 — continuous evidence vs. quarterly theater.

✦ 7. Third-Party Integration Exposure: Who Has Access to Your Environment?

What to check: List every third-party SaaS integration that has credentials into your environment. For each: What can they access? When were their credentials last rotated? What happens to access if you cancel the subscription?

What good looks like: A documented integration inventory. Each integration's access scope is justified by its function. Offboarding procedures exist for integrations.

What most companies find: Nobody has a complete list. Integrations were approved by individual teams, not security. Some have broader access than their function requires (a monitoring tool with write access to the systems it monitors). Cancelling a subscription doesn't automatically revoke credentials.

Board answer you need: "We have X third-party integrations with credentials in our environment. Here's their scope, owner, and rotation status."

Good vs. What Most Companies Find

| Check | Good | Typical | |-------|------|---------| | Service account inventory | Complete list, known owners | Count unknown, no owner records | | Credential age | <20% over 90 days | Majority never rotated | | Privilege scope | <5% elevated, all justified | 20–40%+ elevated, most unjustified | | Orphaned accounts | 24hr offboarding SLA | Orphans from years ago still active | | API key rotation | Automated, on schedule | Manual, last rotated at creation | | Compliance evidence | Audit-ready in 24h | Assembled manually before audit | | Third-party integrations | Full inventory, scoped access | Incomplete list, overbroad access |

If you're in the "typical" column on most of these, you're not unusual — but you are exposed. And your board deserves to know what you're doing about it.

What This Has to Do With Non-Human Identities

The reason this audit is hard for most organizations is structural. The access governance tools built over the last decade were designed for human users: provision, review, deprovision. They assume someone is logging in. Service accounts don't log in — they authenticate programmatically, continuously, often without any human-visible activity.

The result: NHI accounts exist in a governance blind spot. Your IDP has them. Your cloud IAM has them. But the tooling you use to enforce access policy — the review workflows, the certification campaigns, the anomaly detection — wasn't built with them in mind.

That's the access governance blind spot that lets credential age, privilege scope, and orphaned accounts accumulate undetected.

How Vigil Automates This Audit

The 5-minute checklist above is a snapshot. Vigil turns it into a continuous live view.

Inventory: Vigil discovers and catalogs all service accounts, API keys, and machine credentials across your environment — not just what's in your IDP, but what's actually in use.

Credential hygiene: Automatic tracking of credential age, rotation status, and last-used date. Flags before they become risks.

Privilege analysis: Every service account's actual permission scope, compared to its observed access patterns. Least-privilege gaps surface automatically.

Orphan detection: Accounts that haven't been used in 30/60/90 days are flagged. Accounts linked to decommissioned services are automatically identified.

Compliance evidence: Continuous, audit-ready documentation for every access grant and review — not a pre-audit scramble.

The board question changes from "do we have this exposure?" to "here's our live posture."

See how Vigil compares to other NHI governance tools →

Before Your Next Board Meeting

Walk in with answers to these seven questions:

1. How many service accounts exist, and who owns them? 2. What percentage of credentials are within rotation policy? 3. How many accounts have elevated privileges, and are they justified? 4. What's our orphaned account detection and remediation process? 5. Are API keys for critical integrations on an automated rotation schedule? 6. Can we produce NHI-specific compliance evidence on demand? 7. What third-party integrations have access, and what can they reach?

If you can answer all seven confidently, you're ahead of most. If you can't — use this checklist as the starting point for the remediation conversation, not just the audit one.

Ready to get your NHI audit answers automatically? Book a demo with Vigil to see how to go from "we don't know" to audit-ready posture in under 48 hours.