Keep Azure privileged access clean

Cleaning up privileged access is one of the cheapest security capabilities to act on in pure Azure-spend terms. Revoking the role assignment of an inactive identity, or removing a stale Owner grant, does not change your bill at all. The only real cost sits in the just-in-time piece: converting permanent privileged roles to eligible, time-bound access through Microsoft Entra Privileged Identity Management requires Microsoft Entra ID P2 or Microsoft Entra ID Governance licensing, which is a per-administrator licence cost, not an Azure resource charge. The inactive-identity recommendation itself surfaces through Defender for Cloud's cloud infrastructure entitlement management, which is part of the Defender CSPM plan.

Frame each failing recommendation as a line on the risk register rather than a compliance checkbox. A permanent Owner assignment held by a service principal carries a far higher expected loss than a Reader role that has gone inactive, yet both surface as findings in the same group. Map each one to what the identity can actually do and prioritise by blast radius, not by finding count.

The insurance arithmetic is one-sided. The remediation is engineering time, plus a bounded, well-understood licence cost for the administrators who genuinely need privileged access on demand. The downside of leaving it is the documented cost of a credential-abuse or insider incident: an attacker who phishes one standing Owner account inherits everything that account can do, with no expiry to slow them down.

Sam is the finance partner supporting the platform team's ISO 27001 push. The security report lands with nine identity findings across two subscriptions: five identities flagged as inactive, and four permanent Owner or Contributor assignments at the subscription and resource group level. The instinct is not to wave through a blanket budget; it is to ask what is actually behind each finding. Revoking the access of an inactive identity, or removing a stale Owner grant from a finished project, changes nothing on the Azure bill. The only spend question is narrow: converting the privileged roles that are still genuinely needed to just-in-time access through Privileged Identity Management requires Microsoft Entra ID P2 or Microsoft Entra ID Governance licences, one per administrator who needs on-demand privilege, and the inactive-identity findings surface through the Defender CSPM plan, which the team has already turned on.

Sam asks the team to map each finding to the identity behind it. Two are service principals from finished migrations that still hold Owner, three are contractors whose engagements ended but whose roles were never removed, and four are current engineers who legitimately need Owner from time to time. The list is reframed: the five unused grants are zero-Azure-cost revocations to close today, and the four live administrators become the scope of a bounded licence purchase so their access can be made just-in-time. The finance pack reads: 'Five findings revoke at no incremental spend; four legitimate administrators need a per-seat licence to move to just-in-time access; the only thing standing between us and a clean posture is engineering time plus a small, countable licence line.'

The cost model here is asymmetric in a way that is rare for security work. Revoking unused privilege costs nothing in Azure spend, and the just-in-time conversion costs a bounded, countable per-administrator licence. Against that sits an unbounded tail risk: every standing Owner or Contributor assignment is an account whose compromise hands an attacker broad control with no expiry, and every inactive identity is a credential nobody is watching. The probability of any single account being compromised is low, but the probability across all standing privileged accounts over years is not, and the loss when it happens is near-total for whatever that account can reach.

The documented cost of a privileged-access breach includes the full incident: forensics to work out everything the account touched, regulatory notification within tight windows, legal and reputational fallout, and often a forced rebuild because you can no longer trust the integrity of resources an Owner account controlled. Against that, the remediation is engineering time plus a small, well-understood licence line for the administrators who genuinely need on-demand privilege. The finance role is to attach expected loss to each failing assignment, weighted by what the identity can do, so the work is prioritised by blast radius rather than by the order the report lists it.

Privileged access is the category of risk where a single compromised credential turns into total control. An attacker who phishes an account that holds permanent Owner over a subscription inherits everything that account can do, and there is no expiry to slow them down. The report shows this as a scatter of separate findings: identities that have gone inactive but kept their access, and powerful roles assigned permanently when they should be granted only on demand.

The leadership question is not 'who has access today?' It is 'if one of our administrator accounts is compromised tomorrow, how much can the attacker reach, and for how long?' The defensible end state is that nobody holds privilege they do not actively use, and that the high-powered roles are granted just-in-time and expire on their own, so a stolen credential is far less useful and far shorter-lived.

The Azure-spend cost of reaching that state is close to nothing. The only meaningful cost is the per-administrator licensing for just-in-time access. This is a governance decision about whether standing privilege is the default or the exception, not a budget decision.

After a peer company disclosed a breach that started with a single phished administrator account holding permanent Owner across their estate, the CEO asked the obvious question at the next review: how much could one compromised account reach here, and for how long? The honest answer at the time was that several accounts and a couple of forgotten service principals held standing Owner, so a single stolen credential would have inherited broad control with no expiry to slow it down.

The team's response was to stop treating privileged access as a per-grant cleanup and start treating it as a default. They listed every identity holding Owner or Contributor, revoked the assignments that belonged to finished projects and departed contractors, and converted the access of the engineers who genuinely needed it from permanent to eligible through Privileged Identity Management, so those roles now have to be requested, are time-boxed, and expire on their own. The next time the CEO asked the question, the answer had changed from 'one account could reach almost everything, indefinitely' to 'no account holds standing Owner; privilege is requested when needed and expires within hours.' That shift, from standing access being the default to being a documented exception, is the one-line confidence signal this capability delivers.

Nearly every major cloud breach that escalated from a single stolen credential into total compromise came back to the same root cause: an account that held more standing privilege than it needed to. Cleaning up privileged access is the capability that makes that root cause structurally difficult, and just-in-time access through Privileged Identity Management makes the most dangerous version of it, a permanent Owner credential, close to impossible: there is nothing standing for an attacker to inherit.

The cost of getting this wrong is large and well documented, while the cost of fixing it is engineering time plus a bounded per-administrator licence. This is the rare class of control where the risk of inaction is severe and the cost of action is small and countable, which is exactly the trade leadership should be quickest to approve.