Compliance

Remove stale and external Azure identities

One capability across blocked, deprecated, external and guest accounts: make sure no identity that has left, been disabled, or belongs to another organisation still carries standing access to your Azure subscriptions and resources, unless you genuinely intend it.

14 min·10 sections·AZURE

Last reviewed 18 June 2026

Remediates Microsoft Defender for Cloud: azure-blocked-accounts-owner-removed azure-blocked-accounts-readwrite-removed azure-deprecated-owner-accounts-removed azure-external-accounts-read-removed azure-external-accounts-write-removed azure-guest-accounts-owner-removed azure-guest-accounts-read-removed azure-guest-accounts-write-removed

Removing stale identities: the basics

What does a stale or external Azure identity actually look like?

A role assignment on a subscription is a standing grant: it stays in place until someone removes it, regardless of what happens to the person or the account behind it. Exposure here shows up in a handful of distinct shapes rather than one setting. A blocked account is one that has been disabled from signing in to Microsoft Entra ID, usually because someone left, but whose RBAC grant on your resources was never cleaned up. A deprecated account is Defender for Cloud's name for that same blocked account when it still holds a role on a subscription. An external account is a sign-in from a different domain, an identity that lives in someone else's directory. A guest account is a B2B user provisioned into your tenant from outside it. Each is its own Defender for Cloud recommendation, but the underlying risk is the same: an identity that should not, or no longer should, be able to act on your estate still can.

Microsoft Defender for Cloud turns each of these into its own recommendation, split further by the level of access the identity holds, owner, write, or read, which is why one subscription can fail several identity checks at once. 'Blocked accounts with owner permissions on Azure resources should be removed' and 'Deprecated accounts with owner permissions should be removed from subscriptions' close the door on people who have gone; 'External accounts with owner permissions should be removed from subscriptions' and the guest-account recommendations close the door on identities you do not manage. They read as separate problems on the report, but they are one job: every account that can act on the estate is one you intend, manage, and can hold accountable.

Most of this exposure is drift, not intent. A contractor offboarded in Entra but never removed from the subscription. A partner invited as a guest for one project and forgotten two projects later. An owner grant handed to an external email during a migration that nobody walked back. The work is to find every identity that is blocked, deprecated, external or guest and still carries a role, decide which handful are external collaborators you genuinely rely on, govern those properly, and remove the rest.

In this lesson you will learn how Azure expresses standing access through role assignments, how blocked, deprecated, external and guest identities each become a Defender for Cloud finding, how to find every stale or external grant across a subscription, and how to remove them without locking out the collaborators you genuinely need. The Controls this lesson covers section lists every Defender for Cloud recommendation in this capability, each linking to a deep page with the exact check and a copy-and-paste fix.

Fun fact

The account that left but never logged off

A recurring finding in post-incident reviews is the departed insider whose access outlived their employment. The account is disabled in the directory, so it looks gone, but a role assignment on a subscription is a separate object that nobody removed, and a disabled directory account does not automatically lose its RBAC grants. Defender for Cloud labels these 'deprecated' or 'blocked' accounts precisely because they are the quiet ones: not in active use, easy to overlook, and exactly what an attacker looks for when hunting a way in that nobody is watching. Removing the role assignment, not just disabling the sign-in, is what actually closes the door.

Finding stale and external access across a subscription

Sam is the security lead at a scale-up preparing for its first ISO 27001 audit. Defender for Cloud shows identity findings spread across two subscriptions: blocked and deprecated accounts that were offboarded in Entra but never removed from RBAC, plus a handful of external and guest accounts left over from old partner projects.

Rather than work the findings one by one, Sam starts by listing the role assignments on the subscription and picking out the ones held by external identities, the sign-ins from another domain, so the genuine collaborators can be separated from drift before anything is removed.

Start by listing role assignments held by external identities. Guest and external sign-ins carry '#EXT#' in their principal name, which makes them easy to spot.

$ az role assignment list --all --include-inherited --query "[?contains(principalName, '#EXT#')].{who:principalName, role:roleDefinitionName}" -o table

Who Role

----------------------------------------------- -----------

partner_acme.com#EXT#@contoso.onmicrosoft.com Owner

auditor_kpmg.com#EXT#@contoso.onmicrosoft.com Reader

# partner_acme.com holds Owner from a project that ended last year. Close it first.

An external identity holding Owner is the highest-value target in this group. The level of access sets the priority: owner before write before read.

How Defender for Cloud decides an identity is stale or externaldeep dive

These recommendations resolve to two things: the state of the identity in Microsoft Entra ID, and the role assignments that identity holds on a scope. A blocked or deprecated account is one whose 'accountEnabled' property is false, it has been disabled from signing in, yet a role assignment on a subscription or resource still references its object ID. An external or guest account is one whose home directory is not your tenant: in role-assignment output its 'principalType' is User but its 'principalName' carries the '#EXT#' marker, and in the directory its 'userType' is Guest. Defender then splits each into owner, write and read variants based on the role definition behind the assignment, which is why a single stale identity can raise several findings.

An important distinction sits behind the names. Some of these recommendations have a matching built-in Azure Policy and some do not. The 'Deprecated accounts' and 'External accounts' recommendations each map to a built-in auditIfNotExists policy, so you can assign them to keep the assessment running on a schedule. The 'Blocked accounts' and 'Guest accounts' recommendations carry the note 'No related policy', they are assessed by Defender for Cloud's own identity scanner rather than by an assignable policy, so the remediation for those is operational, removing the assignment, rather than policy enforcement.

Defender for Cloud evaluates these against the Microsoft Cloud Security Benchmark on a periodic cycle, so removing an assignment does not flip the recommendation to Healthy instantly. The RBAC change itself is immediate, the access is gone, but the posture catches up on the next assessment. This matters when you are gathering audit evidence against a deadline. Note too that removing a role assignment removes the access, not the directory object; for a leaver you also disable or delete the account in Entra, and for a guest you can remove the guest object once no scope depends on it.

What is the impact of leaving stale or external access in place?

The direct impact is unmonitored access by an identity you do not control. A blocked or deprecated account belongs to someone who has gone, yet if its credential is ever recovered or the directory account is re-enabled, the standing role assignment springs back to life with whatever it granted. An external or guest account lives in another organisation's directory, governed by their password policy, their multi-factor enforcement and their offboarding, not yours, so an owner grant to an external email is an owner grant to a security posture you cannot see. The overwhelming majority of these grants are accidents: a role left in place after a person left or a project ended.

The second-order impact is accountability and blast radius. Every standing grant to an account you do not manage is access you cannot reliably attribute, monitor or revoke at speed during an incident. Owner is the worst case, because it includes the right to grant access to others, so a single stale owner can quietly widen the door further. Removing stale and external grants shrinks the set of identities that can act on the estate to the ones you employ, manage and can hold accountable, which is the only set you can actually defend.

On the compliance side, every modern framework, ISO 27001, SOC 2, HIPAA, PCI DSS and the UK and EU data-protection regimes, expects evidence of joiner-mover-leaver hygiene and periodic access review: that access is removed when people leave and that third-party access is governed and time-bound. A clean set of identity recommendations across every subscription, backed by an access review for the external collaborators you keep, is the cheapest and most defensible artefact you can hand an auditor.

How do you remove stale access safely?

Work the capability as one loop rather than chasing individual findings. The order matters: identify the external collaborators you genuinely rely on before you start removing things, so you do not cut off an active partner or auditor.

1. Inventory every identity by state and access level

List the role assignments on each subscription and classify the principals: blocked or deprecated (accountEnabled is false in Entra), external or guest (the '#EXT#' marker, userType Guest), and the rest. Record the level of access each holds, owner, write or read. Treat this inventory as the source of truth, not the Defender finding count, because one stale identity can trigger several recommendations at once.

2. Separate genuine external collaborators from drift

Most external and guest access is leftover. For each external or guest identity, decide whether the engagement is still live. A current partner or auditor is legitimate and should move to governed, time-bound access through a Microsoft Entra access review or Privileged Identity Management eligible assignment, never a standing owner grant. Everything else, and every blocked or deprecated account of someone who has left, is drift and can be removed.

3. Remove access, highest impact first

Remove the role assignment for each stale grant, owner before write before read, and for a leaver also disable or delete the Entra account so the identity itself is gone, not just its access. Prioritise production and data-bearing scopes over sandboxes. Each removal is a single command per assignment and takes effect immediately.

4. Keep it shut with policy and process

Assign the built-in auditIfNotExists policies for deprecated and external accounts so the assessment keeps running on a schedule, wire offboarding so disabling a leaver also removes their grants, and put the external collaborators you keep into a recurring Entra access review so their access expires unless re-justified. That turns a one-off cleanup into a lifecycle guarantee.

# Remove the highest-impact stale grants first: external/guest identities holding Owner.
SCOPE="/subscriptions/00000000-0000-0000-0000-000000000000"
az role assignment list --scope "$SCOPE" --all --include-inherited \
    --query "[?contains(principalName, '#EXT#') && roleDefinitionName=='Owner'].principalId" -o tsv |
while read -r oid; do
  az role assignment delete --assignee-object-id "$oid" --scope "$SCOPE"
  echo "$oid: external Owner assignment removed"
done

# Find blocked/deprecated (disabled) accounts that still hold a role on this scope.
for oid in $(az role assignment list --scope "$SCOPE" --all \
    --query "[?principalType=='User'].principalId" -o tsv | sort -u); do
  enabled=$(az ad user show --id "$oid" --query accountEnabled -o tsv 2>/dev/null)
  if [ "$enabled" = "false" ]; then
    echo "$oid is disabled in Entra but still holds a role - remove its assignment"
  fi
done

# Keep it shut: assign the built-in deprecated-owner policy by its exact display name
# (look the id up at runtime - never hardcode a policy GUID).
pid=$(az policy definition list \
  --query "[?displayName=='Deprecated accounts with owner permissions should be removed from your subscription'].name" -o tsv)
az policy assignment create \
  --name audit-deprecated-owners \
  --policy "$pid" \
  --scope "$SCOPE"

Quick quiz

Question 1 of 5

Defender for Cloud shows findings across blocked, deprecated, external and guest accounts on several subscriptions. What is the most efficient way to think about them?

Keep learning

Go deeper on how Azure expresses standing access and how to govern the external collaborators you keep across the settings in this capability.

You can now treat stale and external identities as one capability rather than a scatter of findings: inventory who holds a role and at what level, separate the external collaborators you genuinely rely on and move them to governed, time-bound access, remove every blocked, deprecated and orphaned external grant highest-impact first, and keep the estate shut by wiring removal into offboarding and access review. The Controls this lesson covers section below links every recommendation in this group to its deep page and fix.

Back to the library

Removing stale identities: the cost and risk view

A zero-cost capability that removes a whole class of standing-access and insider-risk liability

Stale and external access is one of the cheapest categories of risk to close and one of the most expensive to ignore. Removing a role assignment from a blocked, deprecated, external or guest account costs nothing in Azure spend. There is no meter, no service to provision, no migration. The only real cost is the small amount of governance work around the few external collaborators you genuinely need, who should move to managed, time-bound access rather than a standing owner grant.

Frame each failing recommendation as a line on the risk register rather than a compliance checkbox. An external email holding owner on the production subscription carries a far higher expected loss than a former contractor with read access on a sandbox, yet both can surface as a single red finding. The level of access, owner versus write versus read, and the sensitivity of what sits under that scope, are what set the priority. Map the failures to who and what is behind them and prioritise by exposure, not by recommendation count.

The insurance arithmetic is one-sided. The remediation is mostly a few commands plus a small amount of access-review process. The downside of leaving it is the documented cost of access through an account you no longer control or never managed: a departed employee or a compromised partner identity acting on your estate, with the breach notification, forensics, legal fees and reputational damage that follow.

This lesson is for the finance partner who sees a cluster of identity findings on the security report and wants to know what the right response is and what it costs. It covers why removing stale access is free in Azure spend, why the only real cost is a little governance around the external collaborators you keep, and how to turn a list of red findings into a risk-ordered remediation plan led by the level of access each account holds.

Fun fact

The account that left but never logged off

How a finance partner frames the stale-access decision

Sam is the finance partner supporting the platform team's ISO 27001 push. The security report lands with fourteen identity findings spread across two older subscriptions. The instinct is not to wave through a blanket remediation budget; it is to ask who is actually behind each red finding and what they can do. Removing a role assignment from a blocked, deprecated, external or guest account changes nothing on the Azure bill, so there is no spend question on the removals at all. The only cost is process: the small amount of governance work to put the external collaborators you keep onto managed, time-bound access instead of a standing grant.

Sam asks the team to map each failing account to the person behind it and the level of access they hold. Two are external emails with owner on production, left from partner projects that ended; three are blocked accounts of former staff still holding contributor; the rest are guests with read on non-sensitive scopes. The list is reframed on the risk register: the two external owners are high expected-loss items to remove today at zero Azure cost, the blocked former-staff grants are next, and the read-only guests are low-value drift to sweep up or move into a quarterly access review. The finance pack reads: 'Every removal closes at no incremental spend; the only ongoing work is governing the handful of external collaborators we genuinely rely on. The thing standing between us and a clean posture is process, not budget.'

Why stale and external access belongs on the risk register

The cost model here is asymmetric in a way that is rare for security work. Removing stale and external grants costs nothing in Azure spend, and leaving them in place creates a standing tail risk: each one is an account, outside your control, that could be used to act on your estate. The probability per account in any given month is low, but across every forgotten leaver and every lapsed partner over years it is not, and owner-level grants carry the heaviest expected loss because they can widen access further.

The documented cost of access through an unmanaged account includes mandatory breach notification within tight regulatory windows, forensics and legal fees that routinely run into six and seven figures, and the reputational damage of disclosing that a former insider or a partner identity reached your data. Against that, the remediation is a few commands plus a small amount of access-review process for the collaborators you keep. The finance role is to attach expected loss to each failing account, weighted by its level of access and the sensitivity of its scope, so the work is prioritised by risk, not by the order the report lists it.

What finance can do about the stale-access gap

Finance cannot remove a role assignment, but it owns the framing that turns a scatter of red findings into a risk-ordered plan with zero incremental Azure spend and a clearly bounded set of governed exceptions. Three levers.

1. Make explicit that the removals are free

Removing a role assignment from a blocked, deprecated, external or guest account does not move the Azure bill at all, there is no meter behind access. The only ongoing cost is the modest process of governing the external collaborators you keep through access reviews. State this plainly so nobody can claim the capability is a spending decision; it is a process and discipline decision.

2. Order the work by access level and scope sensitivity

An external email with owner on production and a former contractor with read on a sandbox can both show up as a single red finding, but their expected loss differs by orders of magnitude. Ask the team to map each failing recommendation to who holds it, what level of access it grants, and what sits under that scope, then remediate owner-on-production first. The metric that belongs on the cost-and-security review is the count of stale grants weighted by access level and scope sensitivity, not the raw total.

3. Require governed, documented exceptions for kept external access

Any external partner or auditor whose access is genuinely needed should sit in a recurring access review with an owner and an expiry, not a standing grant. The distinction between 'we reviewed this collaborator and gave them time-bound, monitored access' and 'we never noticed they still had owner' is exactly what makes the posture defensible at audit and in the aftermath of any incident.

Quick quiz

Question 1 of 5

A security report shows fourteen stale-identity findings. As the finance partner, what is the right starting assumption about their Azure-spend cost to remediate?

Keep learning

Go deeper on how Azure expresses standing access and how to govern the external collaborators you keep across the settings in this capability.

You have finished the finance view of removing stale access. You know the cost model is one-sided: every removal is free in Azure spend, the only ongoing cost is governing the handful of external collaborators you keep, and the downside of leaving the grants open is the documented and unbounded cost of access through an account you no longer control. Next time a cluster of identity findings lands, you will order them by access level and scope sensitivity, ring-fence the real collaborators into an access review, and ask for them on the record rather than asking how much remediation will cost.

Back to the library

Removing stale identities: the headline

Whether anyone who has left, or anyone you do not manage, still has standing access to the estate

Standing access is the category of risk that turns an ordinary departure or a forgotten partner into an open door. An account that has been disabled in your directory but still holds a role, or an external identity with owner permissions you no longer track, is one stolen credential or one disgruntled leaver away from acting on your estate. The report shows this as a scatter of separate findings across subscriptions.

The leadership question is not 'are we compliant today?' It is 'when someone leaves or a partner engagement ends, does their access actually end with it?' The defensible end state is that no blocked or deprecated account holds a role anywhere, that external and guest access is the small, named set you deliberately rely on, and that each of those is governed by an access review rather than left standing forever.

None of this is a cost decision. Removing standing access is free in Azure terms. It is a governance decision about whether access ends when a person or an engagement does, by design, or only when someone remembers to revoke it.

A short read for the leader who needs to know what a blocked, deprecated, external or guest account with standing access actually represents, why removing it is a governance decision rather than a budget one, and what a defensible end state looks like when access ends with the person or the engagement.

Fun fact

The account that left but never logged off

What it looks like when access ends with the person, not by luck

After a peer company disclosed that a former contractor's still-live access had been used to reach production months after they left, the CEO asked the obvious question at the next review: when someone leaves us, does their access actually go with them? The honest answer at the time was that it depended on whether anyone had remembered to remove the role assignment, because disabling a leaver in the directory and stripping their RBAC grants were two separate steps and only the first was reliably done.

The team's response was to stop treating identity as a per-account cleanup and start treating it as a lifecycle guarantee. They listed every blocked, deprecated, external and guest account that still held a role, removed the ones tied to people who had gone or projects that had ended, moved the genuine external collaborators onto governed, time-bound access through an access review, and wired offboarding so that disabling an account also queued the removal of its grants. The next time the CEO asked the question, the answer had changed from 'we believe so' to 'no standing access survives a departure, and every external identity is a named, reviewed exception.' That shift, from relying on everyone remembering to revoke to making revocation part of the lifecycle, is the one-line confidence signal this capability delivers, and it costs nothing in Azure spend to reach.

Why this is a board-level risk

Nearly every insider and third-party breach traces back to the same root cause: an identity that should no longer have had access still did, because revoking it was a manual step nobody owned. Removing stale and external access is the capability that makes that root cause structurally difficult, and wiring it into offboarding and access review makes it close to impossible.

The cost of getting this wrong is large and well documented, while the cost of fixing it is essentially process. This is the rare class of control where the risk of inaction is severe and the cost of action is small, which is exactly the trade leadership should be quickest to approve.

The leadership move on stale access

The executive handle is not to approve each removal individually; it is to require that access ends when a person or an engagement does, by process, and that the small number of kept external collaborators are governed and reviewed, on the record.

1. Set a deadline to reach a backstopped end state

Ask for a date by which the estate is inventoried, every blocked, deprecated and orphaned external grant is removed, the genuine collaborators are in an access review, and offboarding removes a leaver's grants automatically. A lifecycle guarantee that no individual departure can bypass is the difference between checking nobody stale has access today and ensuring nobody stale can keep access tomorrow.

2. Ask for proof, not assurance

The proof that this is closed is not a verbal 'we cleaned it up.' It is a passing set of identity recommendations across every subscription, plus evidence that the deprecated and external audit policies are assigned and the access reviews are running. Because Defender for Cloud assesses on a periodic cycle, ask for that evidence with a little lead time before any audit deadline rather than the morning of.

3. Treat kept external collaborators as named, owned, time-bound exceptions

A small number of external identities are needed on purpose, and that is fine. The leadership requirement is that each is a deliberate, documented decision with an owner, an expiry and an access review, not a standing grant left open. The goal is not zero external access; it is zero ungoverned external access.

Quick quiz

Question 1 of 5

At a board review you ask whether a former-insider-access incident like a competitor's could happen to your estate. What end state should you be looking for as the defensible answer?

Keep learning

Go deeper on how Azure expresses standing access and how to govern the external collaborators you keep across the settings in this capability.

Two takeaways. Stale and external access is the rare control where the risk of inaction is severe and the cost of action is essentially process, so it is the trade you should be quickest to approve. And the defensible end state is not 'we disabled the leavers'; it is that no blocked or deprecated account holds a role, every external identity is a named, time-bound, reviewed exception, and offboarding removes access automatically, so access ends when the person or the engagement does, by design.

Back to the library

Controls this lesson covers

One capability, many Microsoft Defender for Cloud recommendations. This lesson is the shared playbook; each control below keeps its own deep page with the exact check, severity and a copy-and-paste fix.

Subscription / RBAC

Part of the learning path Harden Azure identity

Remove stale and external Azure identities

Removing stale identities: the basics

The account that left but never logged off

Finding stale and external access across a subscription

How Defender for Cloud decides an identity is stale or externaldeep dive

What is the impact of leaving stale or external access in place?

How do you remove stale access safely?

1. Inventory every identity by state and access level

2. Separate genuine external collaborators from drift

3. Remove access, highest impact first

4. Keep it shut with policy and process

Quick quiz

Keep learning

Removing stale identities: the cost and risk view

The account that left but never logged off

How a finance partner frames the stale-access decision

Why stale and external access belongs on the risk register

What finance can do about the stale-access gap

1. Make explicit that the removals are free

2. Order the work by access level and scope sensitivity

3. Require governed, documented exceptions for kept external access

Quick quiz

Keep learning

Removing stale identities: the headline

The account that left but never logged off

What it looks like when access ends with the person, not by luck

Why this is a board-level risk

The leadership move on stale access

1. Set a deadline to reach a backstopped end state

2. Ask for proof, not assurance

3. Treat kept external collaborators as named, owned, time-bound exceptions

Quick quiz

Keep learning

Controls this lesson covers

Subscription / RBAC

Related compliance lessons