Reviewing service accounts — the invisible majority

Alongside real employees, you have service accounts: API integrations, scheduled jobs, automation. Often there are more of these than human users. Who owns them, and how do you review them?

Service accounts are non-human identities: the Zapier integration, the GitHub Actions bot, the nightly backup runner. They live long, often carry broad permissions, and are rarely reviewed.

Take stock of them

\n
• All M365/Entra app registrations: what do they do, and who created them?
\n
• GitHub deploy keys and app installations.
\n
• API users in your CRM, accounting software, and customer portal.
\n
• Database users outside your main user table.
\n
• CI/CD credentials.
\n

For each service account, record

\n
• A human owner (name, and who takes over when they leave).
\n
• Purpose / what the account does.
\n
• Scope / permissions.
\n
• Where credentials are stored.
\n
• An expiry date (ideally) or next review date.
\n

Review cadence

At least annually, ideally every six months. For each item: still needed? Permissions still minimal? Credentials rotated recently?

When an owner leaves

Every service account must be handed to a new human owner — otherwise it quietly dies during offboarding and no one notices what depended on it. See vault handover.