Service Account Governance in Entra ID and AD

Walk into most Microsoft tenants and you will find two very different worlds. Human identities get onboarding checklists, access reviews, MFA, and offboarding tickets. Service accounts get created once, given far more permission than they need "to be safe," and then left alone for years. Service account governance is the practice of closing that gap: applying the same discipline to non-human identities that you already apply to people. It sounds obvious once you say it out loud. In practice, almost nobody does it consistently.

That gap is not a small oversight. Service accounts, app registrations, managed identities, and automation accounts often hold standing, high-privilege access with no MFA, no owner who checks in regularly, and a password or secret that was set once and never rotated. They are exactly the kind of account an attacker looks for, and exactly the kind of account most identity governance programs quietly skip. This article covers why service accounts get treated differently, what governing them actually looks like, and how to bring them into the same access model you use for humans.

Why Service Accounts Fall Through the Cracks

Non-human identities are not neglected because nobody cares. They are neglected because the normal governance machinery was built with people in mind.

They do not go through HR

Every human account is tied to a lifecycle event: hired, promoted, transferred, terminated. That lifecycle is what triggers access reviews, offboarding, and manager sign-off. A service account has no HR record. Nobody's departure triggers a review of the service accounts they created. They just keep running, quietly, long after the project or the person is gone.

Ownership is fuzzy by design

A human account has an obvious owner: the person using it. A service account is created by one engineer, used by an application or script another team maintains, and eventually nobody can say with confidence who is accountable for it. When ownership is unclear, review cycles have nothing to attach to, and the account defaults to being left alone.

Breaking them is scary, so nobody touches them

Disabling a human account that turns out to still be needed is an inconvenience. Disabling a service account that turns out to be running a nightly batch job or an integration nobody documented can take down a system. That asymmetry pushes IT teams toward doing nothing, which is how privileged accounts accumulate for a decade without a single review.

They tend to be over-provisioned from day one

Under deadline pressure, it is common to grant a service account Global Administrator or a broad Contributor role "just so it works," with a mental note to scope it down later. That later rarely comes. The result is a population of accounts with far more standing privilege than the task actually requires.

What Good Service Account Governance Looks Like

Governing non-human identities is not about treating them exactly like people. It is about applying the same underlying principles, adapted to how machines actually work.

Every account needs a named, accountable owner

Not a team, not a shared mailbox, a person. The owner is who gets asked when the account comes up in a review, and who is responsible if it needs to be rotated, scoped down, or retired.

Purpose and scope should be documented, not assumed

What does this account do, what does it connect to, and what does it actually need access to? A one-line description at creation time saves hours of investigation later, when someone finds an unfamiliar account with domain admin rights and has to figure out if it is safe to touch.

Credentials need a rotation and expiry policy

Certificates and secrets for app registrations and service principals should have expiry dates and a rotation process, the same way a password policy applies to people. An account with a secret that never expires is a standing risk that only gets riskier with time.

Access should be scoped to what the task requires

The same least-privilege thinking that applies to a new hire's group memberships applies here. A service account that only needs to read a mailbox should not also have write access to every SharePoint site in the tenant.

Reviews need to happen on a schedule

Service accounts should appear in the same recurring access review cadence as human accounts, not a separate process that gets deprioritized every quarter. If nobody can confirm an account is still needed, that is itself a finding worth acting on.

Building an Inventory: You Cannot Govern What You Cannot See

The first real step in service account governance is almost always discovery, because most organizations do not have a reliable list of what exists.

Where non-human identities hide

• On-prem AD service accounts, often created years ago for a specific application and never documented centrally.
• Entra ID app registrations and enterprise apps, some with client secrets or certificates nobody remembers issuing.
• Managed identities, which are lower risk by design but still need to be tracked as part of the full picture.
• Automation and runbook accounts, used for scheduled scripts and integrations, frequently over-permissioned "to be safe."
• Shared or generic accounts masquerading as service accounts, created for a person to log in as instead of using their own identity, which blurs accountability further.

A simple classification helps prioritize

Signal	What it tells you
No recent sign-in or usage activity	Candidate for disabling or removal
Privileged role (Global Admin, Domain Admin) with no documented owner	High-priority investigation
Secret or certificate near or past expiry	Rotation or retirement needed
Broad permissions but narrow, known purpose	Candidate for scoping down
Shared credentials used by multiple people	Should be replaced with individual accounts or managed identity

Once you have an inventory, ranking by privilege level and by how stale the account looks gives you a practical order to work through, instead of trying to fix everything at once.

Applying Access Rules Consistently, Not Just to People

The underlying idea behind good access governance is that access should follow a defined set of rules, not a person's memory of what was granted and why. That principle does not stop being true because the account is non-human.

Attribute-based rules work for service accounts too

Just as human access can be driven by attributes like department, job title, and location, service accounts can be governed by attributes like environment (production versus test), application, and function. A service account tagged as belonging to a specific application and environment can be scoped, reviewed, and audited against that classification, rather than relying on someone remembering what it was for.

Group membership still matters

On-prem AD and Entra ID groups remain the mechanism through which most privilege is granted, whether the member is a person or a service principal. ServiceChanger's access automation applies the same rule-based group assignment to accounts based on their attributes, which means a service account's group memberships stay consistent with its documented purpose, instead of drifting as ad hoc permissions get bolted on over time.

Access reviews should include non-human identities by default

Access reviews built around ServiceChanger cover the groups and roles that service accounts participate in, so a stale, over-privileged, or ownerless service account surfaces in the same recurring review as a stale human account, rather than living in a blind spot.

Where License and Asset Governance Intersect

Service accounts are not just an access risk, they also show up in license and device conversations in ways that are easy to miss.

Service accounts and license consumption

Some service or system accounts are inadvertently assigned Microsoft 365 licenses they do not need, either from being added to a licensing group by mistake or from a leftover assignment nobody cleaned up. ServiceChanger's license module surfaces license usage based on real Entra ID sign-in activity and contract data, which makes it easier to spot a licensed account that is clearly not a human user signing in regularly, and flag it for review.

Keep the scope honest

None of this replaces a security review of exactly what permissions a given service account holds. Governance tooling gives you visibility and consistent rule enforcement around group membership and access, not a substitute for scoping the underlying permissions correctly in the first place.

FAQ

What is a service account in Entra ID or Active Directory? A service account is a non-human identity used by an application, script, or automated process to authenticate and access resources, rather than being tied to an individual user logging in.

Why are service accounts a bigger security risk than user accounts? They often carry standing, high-privilege access, rarely use MFA, and are reviewed far less often than human accounts, since no HR event triggers a check on them. That combination makes them an attractive target if credentials are compromised.

Should service accounts go through the same access reviews as employees? Yes. Including them in the same recurring review cadence, rather than a separate or ad hoc process, is one of the most effective ways to catch stale or over-privileged accounts before they become a problem.

Can attribute-based access control be applied to service accounts? Yes. Attributes like environment, application, and function can drive group membership and access for service accounts in the same way department, job title, and location drive access for people.

Service accounts do not need a separate governance philosophy, they need the same rules applied consistently. For a broader look at keeping access clean and auditable across your Microsoft environment, see our guide to access governance and compliance. To go deeper on the mechanics of rule-based access, browse our Entra ID and access control articles. If you want to see how ServiceChanger applies consistent, attribute-based rules to every account in your tenant, human or not, get in touch to see it in action.