Service account, API key and non-human identity cleanup
Cohash cleans up non-human identities. Active Directory service accounts, Entra ID app registrations, cloud roles and keys, SaaS OAuth grants, API keys, AI agents. We build one inventory, give every identity an owner and remove what's unused. Then we move workloads to federation and managed identities, rotate or vault whatever has to stay static, and add the survivors to access reviews in SailPoint, Saviynt or Entra ID Governance.
- 01Inventory
- 02Owners and dead weight
- 03Federate first
- 04Rotate or vault the rest
- 05Governance
The story
Told without the client's name or anything that could identify them.
A healthcare company's identity team had more service accounts than people in Active Directory, most with no owner, and app registrations holding client secrets that never expired. It became urgent when Microsoft's mandatory MFA for Azure sign-ins reached phase 2 and scripts that still signed in as users began to break. We pulled service accounts, app registrations, cloud keys, SaaS OAuth grants and agents into one inventory and joined them on owner, last use and permissions. Unowned and unused identities went through disable, wait, then delete. Workloads moved to federation and managed identities, and the few static credentials that had to stay went into the vault with rotation.
why it was urgentScripts signing in to Azure as a user have started to break. That's phase 2 of Microsoft's mandatory MFA for Azure sign-ins, in effect from 1 October 2025. Workload identities are exempt. OWASP's 2025 Non-Human Identities Top 10 names improper offboarding and secret leakage among its top risks, along with long-lived secrets. Entra stops auto-granting AgentIdentity.CreateAsManager on 4 November 2026.
- openService accounts outnumber people in Active Directory and most have no owner.
- recurringApp registrations hold client secrets that never expire.
- blockedThere's still a script that signs in to Azure as a user, with a password and an MFA exclusion.
- openNobody can say which SaaS apps hold OAuth grants to the tenant.
- recurringSomebody's AI agents are running on ordinary app registrations with broad Graph permissions.
The estate, before and after
Before: unowned accounts, static secrets and user sign-ins
Scripts signed in to Azure as a user with an MFA exclusion, pipelines and agents used app registrations with long-lived secrets, and Windows services ran on service accounts nobody owned. SaaS OAuth grants were not listed anywhere.
After: owned, federated machine identities under review
We moved workloads to federation and managed identities and gave agents their own identity type. The service accounts that had to stay rotate in the vault. One inventory feeds the certification campaigns, where owners review what their identities can reach.
How we run it, phase by phase.
5 phases take you from Unowned service accounts, keys and app registrations to Owned, federated, short-lived machine identities. Each one ends with something you can check before the next starts. As you scroll, the blocks show the estate moving across.
- phase 01
Inventory
Pull service accounts out of Active Directory and app registrations and service principals out of Entra ID. Get roles and keys from AWS, Azure and Google Cloud, OAuth grants from SaaS, agents from the agent platforms. Join it all on owner, last use and permissions.
- phase 02
Owners and dead weight
Find an accountable owner for every identity in HR data and change records. Disable the ones nobody has used in the agreed window, wait, and delete. Anything unclaimed goes on a dated disable list.
- phase 03
Federate first
Pipelines move to OIDC federation and Azure workloads to managed identities. Kubernetes gets workload identity, and servers outside the cloud use certificate-based roles. Every one of those moves takes a stored secret out of the estate.
- phase 04
Rotate or vault the rest
Identities that must keep a password go into PAM or Vault with rotation, after their dependencies are mapped so rotation doesn't stop a Windows service.
- phase 05
Governance
Add surviving identities and agents to certification campaigns with their owners as reviewers, and set lifecycle rules so new ones need an owner and expiry at creation.
What the client got
What changed for the client once the work was done. Described, not scored: we don't publish client figures.
- result 01
Every machine identity has an accountable owner
We assigned owners using HR data and change records, and agreed escalation to application owners before the review started. Identities nobody claimed were put on a disable list with a date.
- result 02
Pipelines and Azure workloads sign in without stored secrets
OIDC federation, managed identities and Kubernetes workload identity replaced client secrets and scripts that signed in as a user, so nothing depends on an MFA exclusion any more.
- result 03
Unused identities are disabled before they are deleted
Nothing is deleted straight away. It's disabled, left for the waiting period, then deleted, and the rollback steps are written down, so a quarterly job that last-sign-in data missed comes back quickly.
- result 04
Static passwords that remain rotate in the vault
The accounts that still need passwords are in PAM or Vault, and they rotate. We mapped each one's scheduled tasks, app pools and Windows services before onboarding it.
- result 05
Machine identities and agents go through access reviews
Owners now certify their identities in campaigns. We made an owner and expiry mandatory at creation, and moved agents off app registrations and onto agent identity types.
Risks we plan for
-
Disabling something critical
Last-sign-in data can miss a job that runs once a quarter. So we disable first and delete later, with a waiting period and a quick way to turn things back on.
-
Owners who don't answer
Without accountable owners, the inventory just sits there. We agree escalation paths to application owners and their managers before the review begins.
-
Rotation outages
A service account behind scheduled tasks, app pools and Windows services breaks if its password changes in one place but not the others. We map where it's used first.
-
Agents built on borrowed identities
Agents running on app registrations or personal tokens look like everything else in the inventory, so they're easy to miss. Each needs its own identity type and a sponsor.
Where AI helps, and where it needs guardrails
We move agents off app registrations and onto proper agent identities. Microsoft Entra Agent ID, now generally available, gives them identity blueprints, sponsors and access packages. Okta for AI Agents covers registration and certification. We do use AI agents ourselves, to draft owner suggestions and dependency maps from logs. But a person makes every disable, delete and rotation call.
forward deployed engineers →What you're left with
We write these for your setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
- inventory01
Unified non-human identity inventory with owner, last use and permissions
yours to keep - plan02
Disable and delete schedule with rollback steps
yours to keep - plan03
Federation and managed identity migration plan per workload
yours to keep - plan04
Rotation onboarding plan with dependency maps
yours to keep - design05
Certification campaign design for machine identities and agents
yours to keep
Platforms and services on this move
Learn the background
Terms from this page in plain English. If you want the why, the field note behind it is right there.
- 01sponsor
- Whoever in the business answers for an agent. If it misbehaves, they're the one you call, and they decide whether it keeps running. Technical settings stay with the owner.in context →
- 02Service account
- A non-human account that software signs in with. Shared ones tend to pick up years of extra permissions.in context →
- 03Rules
- The JavaScript snippets Auth0 used to run at login. Someone would write one to add a role to the token or block a sign-in, and each one ran after the last.in context →
- 04PAM
- PAM is privileged access management: the vault for admin and service account passwords, which also rotates them and checks who's asking.in context →
- 05dependencies
- Services, scheduled tasks or app pools that use a vaulted account. The vault updates them when the password changes, but only if it knows about them.in context →
- 06Rotation
- Changing privileged passwords automatically, on a timer or after each checkout. If one leaks, it soon stops working.in context →
Certified engineers, wherever you need them.
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Onsite
Engineers at your sites in the US
Nearshore
Overlapping hours with US teams
Offshore
Overnight progress on your backlog
All time zones
Coverage handed over across time zones
01Do we need a dedicated NHI tool?
Not always. Entra ID, your IGA platform and the cloud IAM reports can produce a first inventory between them. A dedicated tool earns its cost when SaaS OAuth grants and secrets are spread over many platforms. We begin with the tools you already own and show you where they fall short.
02How many identities can we safely remove?
You can't tell until last-use data is in the inventory. Plenty of estates hold identities that stopped authenticating long ago. We still put every one through disable, wait, then delete.
03What drives the effort?
The number of systems to pull from, how many identities have no clear owner, and how many workloads need code or pipeline changes to use federation.
Often on the same roadmap
On-premises Active Directory to cloud-first Microsoft Entra ID
We shrink on-premises Active Directory one application at a time, moving groups, users and app authentication to Microsoft Entra ID as each app is ready.
read the case studyAD FS federation to Entra ID authentication
Converting federated domains from AD FS to Entra ID cloud authentication, moving relying parties app by app and retiring the AD FS farm.
read the case studyMoving Auth0 Rules and Hooks to Actions before Auth0 switches them off
Moving Auth0 Rules and Hooks to Actions before Hooks stop on 30 April 2027 and Rules on 31 January 2028, with token claims checked before and after each change.
read the case study567a66d4 - 01Book a 30-minute working sessionsenior engineer
- 02Talk to an engineer about your setupreply within 24 hours
- 03See how similar projects wentcase studies
Planning this move?
A 30-minute working session with a senior engineer. No slides.
- The platform and the version you're on
- Where you need to get to, and by when
- What's custom: rules, plugins, integrations
- Any audit finding or deadline driving it