Your IT team probably runs quarterly access reviews for every employee who joins, moves, or leaves. You have a process for contractors. You might even review admin accounts monthly. What you don’t have is a recurring audit process for the service accounts, API keys, and bot credentials that outnumber your employees three to one and hold more privilege than most of your engineering team.
These machine identities don’t show up in your identity provider’s user list. They don’t trigger deprovisioning workflows when someone leaves. They were created by a developer who needed to ship something fast, granted admin rights “temporarily,” and never reviewed again. Some of them are older than your current CTO’s tenure.
The breach vector isn’t the phishing attack that compromises a user account. It’s the three-year-old API key with full database access that’s hardcoded in a script nobody remembers writing. This checklist covers what to verify before that credential becomes your incident response call at 2 a.m.
Inventory: What Machine Identities Exist Right Now
You can’t review what you can’t see. Most organizations discover their full machine identity footprint only after a breach forces the investigation. Start with a complete credential census before attempting any governance work.
What to document for every machine identity:
- Service accounts in Active Directory, LDAP, or cloud IAM systems
- API keys and access tokens across all SaaS platforms and internal applications
- SSH keys on servers, containers, and CI/CD pipelines
- Database credentials used by applications and automation scripts
- Certificate-based authentication for system-to-system communication
Pull logs from your identity systems, cloud provider consoles, and application configs. Check your secrets management tools if you have them. Check environment variables, config files, and deployment scripts if you don’t. The credentials your security team doesn’t know about are the ones your developers created last quarter to unblock a release.
For teams under 200 employees, expect to find 300 to 500 machine identities. At enterprise scale, the ratio hits 10:1 or worse.
Ownership: Who’s Responsible When a Service Account Is Compromised
Every service account was created by someone. Most of them are now owned by nobody. The developer who spun up that automation bot left the company 18 months ago. The team that built the integration was reorganized. The project that needed those credentials was deprecated, but the credentials weren’t.
When that orphaned service account gets compromised, your incident response team will spend the first six hours just figuring out what it has access to and who might know why it exists.
Assign explicit ownership for every credential type:
- Application service accounts: The team that owns the application in production
- CI/CD pipeline credentials: The platform engineering or DevOps lead
- Infrastructure automation: Whoever manages your IaC and configuration management
- Integration API keys: The business owner of the integration, not just the developer who built it
If you can’t name an owner, the credential is orphaned. Orphaned credentials get disabled immediately or assigned to a designated cleanup owner with a 30-day review deadline. No exceptions.
RED FLAG: Nobody owns the service account
If the original creator left the company or moved teams and no one was formally assigned ownership, you’re managing a credential nobody understands. Disable it and wait for something to break. What breaks will tell you what it was actually used for.
Access Level: What Privileges These Identities Actually Hold
Service accounts follow a predictable lifecycle. They’re created with elevated permissions to solve an immediate problem. The problem gets solved. The permissions never get reduced. Six months later, you have a CI/CD service account with full production database access because someone needed to run a one-time migration script.
Your user access reviews catch privilege creep in human accounts. Nobody’s checking whether the automation bot that posts Slack notifications also has admin rights to your billing system.
Risk-rank every machine identity by privilege level:
- Full admin or root access to any system
- Write access to production databases or customer data stores
- Ability to provision infrastructure or modify IAM policies
- Cross-environment access (service accounts that work in both dev and prod)
- Credentials with no scope limits or expiration dates
Start with the highest-risk tier. If a credential has admin rights and you can’t immediately explain why, that’s your first rotation candidate. For most organizations, 60% to 70% of service accounts are over-privileged. The credentials with the broadest access are usually the oldest ones that were created before your team had a formal provisioning process.
Usage Pattern: Which Credentials Are Active, Dormant, or Orphaned
A service account that hasn’t authenticated in 90 days is either dormant or broken. If it’s dormant, it’s a ghost credential waiting for someone to rediscover it. If it’s broken, something in your environment is failing silently and nobody noticed.
Pull authentication logs for every machine identity in your inventory. Most IAM systems track last-used timestamps. Cloud providers surface this in their access analyzers. If your environment doesn’t log machine identity usage, that’s the infrastructure gap to fix before attempting a review process.
Categorize credentials by activity pattern:
- Active: Authenticated within the past 30 days
- Stale: Last used 30 to 90 days ago, requires owner verification
- Dormant: No activity for 90+ days, candidate for immediate disabling
Disable dormant credentials first and monitor for breakage. What doesn’t break in 72 hours wasn’t critical. What does break gets documented, right-sized for privilege level, and assigned to an active owner. For stale credentials, contact the assigned owner and give them one week to confirm it’s still needed. No response means it gets disabled.
At mid-market scale, expect 20% to 30% of your machine identities to be dormant. At enterprise scale, that number climbs to 40% or higher if you’ve never run this audit before.
RED FLAG: Secrets older than your compliance window
If your compliance framework mandates 90-day password rotation and you’re sitting on API keys that haven’t changed in 18 months, you’re out of policy. Auditors will find this. Fix it before they do, or budget for the finding and the remediation timeline it triggers.
Rotation Status: When These Credentials Were Last Changed
Most organizations have a password policy that forces users to rotate every 60 or 90 days. Almost none of them apply that policy to service accounts. The API key your team created three years ago has never been rotated. The database password embedded in your application config was set during the initial deployment and hasn’t changed since.
Credential age is the single best predictor of whether a machine identity will become a breach vector. The older the credential, the more places it’s been copied, the more people have seen it, and the higher the chance it’s been exposed in a way nobody documented.
| Credential Type | Recommended Rotation | Why It Matters | Red Flag If Missing |
|---|---|---|---|
| API keys | 90 days | Keys get logged, cached, and copied into documentation | No rotation policy or keys older than 12 months |
| Service account passwords | 90 days | Older passwords often predate your current security baseline | Passwords set before your last major security initiative |
| SSH keys | 180 days | Keys accumulate on servers and in admin home directories | Keys with no expiration date or passwordless private keys |
| Database credentials | 90 days | Application configs are the most common source of credential exposure | Credentials embedded in source code or config files in version control |
| TLS/SSL certificates | Before expiration | Expired certificates cause outages; old ones often use deprecated crypto | Certificates using SHA-1 or RSA keys under 2048 bits |
Your rotation policy needs to account for the operational cost of rotating credentials that are embedded in application configs, CI/CD pipelines, and infrastructure code. For teams without secrets management, that cost is high enough that rotation doesn’t happen. If manual rotation is blocking your policy, budget for a secrets manager before you document a rotation cadence you won’t enforce.
Deprovisioning Process: What Happens When a Service or Project Ends
Applications get deprecated. Integrations get replaced. Projects get cancelled. The service accounts created for those initiatives don’t get cleaned up. They sit in your environment with whatever access level they were granted, waiting for someone to remember they exist.
Your user offboarding process disables accounts within 24 hours of an employee’s departure. Your machine identity lifecycle has no equivalent trigger. When a project ends, the credentials live on unless someone manually remembers to revoke them.
Build deprovisioning triggers into your standard workflows:
- Application decommissioning checklist must include service account inventory and revocation
- Project closure requires credential cleanup sign-off from the infrastructure owner
- Integration deprecation triggers API key revocation at both ends of the connection
- Quarterly reviews flag service accounts associated with projects marked complete or cancelled
For every machine identity, document what it supports. When that application, service, or integration is retired, the credential gets disabled immediately. If disabling it breaks something unexpected, you’ve just discovered an undocumented dependency that needs to be mapped before the credential can be safely removed.
The cleanup backlog grows faster than most teams expect. Budget 2 to 4 hours per quarter for a dedicated credential cleanup sprint where someone goes through the stale and dormant lists and disables everything that doesn’t have an active owner confirmation.
Review Cadence: How Often This Audit Needs to Run
User access reviews happen quarterly because regulatory frameworks require it and because user turnover creates obvious risk. Machine identity reviews don’t happen because there’s no compliance driver and no one’s job depends on keeping the list current.
Set a review cadence based on your organization’s size and rate of change. For startups shipping fast, machine identities proliferate quickly. For enterprises with stable infrastructure, the inventory changes more slowly but the volume is higher.
Sustainable review intervals by organization size:
- Under 50 employees: Quarterly full inventory and ownership review
- 50 to 500 employees: Monthly review of new credentials, quarterly full audit
- Enterprise scale: Continuous monitoring with monthly high-risk reviews and quarterly full reconciliation
The first audit will take the longest. Expect 8 to 12 hours of work for a mid-market IT team to complete the initial inventory, assign ownership, and establish the baseline. After that, recurring reviews take 2 to 3 hours per cycle if you’re staying on top of it.
If your team is under three people, the admin overhead will compete with every other priority you’re managing. Start with a six-month cycle and focus only on credentials with admin-level access. Expanding to full coverage can wait until you have the staffing to support it.
The license cost for a privileged access management system is easy to justify once you’ve spent 40 hours manually inventorying service accounts and realized you’ll need to do it again next quarter. Most security tools show you what’s happening after credentials get compromised. This checklist finds the exposure before that happens. Before your next security roadmap conversation, run through the access level and rotation sections and count how many credentials fail both checks. That number is your business case.
Also read: NIST SP 800-63B digital identity guidelines
Related reading
- Agentic AI ROI Enterprise Math: What Process Savings Actually Look Like
- Chatbots vs AI Agents: An Efficiency Audit for Real Operations
- 10 AI Marketing Content Tools That Turn the Painstaking Process Into a Smooth Workflow