Apply least-privilege RBAC on Azure subscriptions

Tightening who can do what on a subscription costs nothing in Azure spend. Removing a surplus Owner, revoking an external partner's access or deleting a blocked account's role assignment does not change your bill. There is no per-fix charge, no migration, no new resource. The only cost is the small amount of Microsoft Entra ID Governance licensing if you choose to adopt Privileged Identity Management and access reviews to keep the set tight over time, and that is a deliberate, bounded decision rather than a remediation expense.

Frame each failing recommendation as a line on the risk register rather than a compliance checkbox. A subscription with eight Owners, two of them external partners and one a blocked former employee, carries a far higher expected loss than a single-Owner sandbox, yet both can surface as a red finding. The blast radius of a compromised or misused Owner account is the entire subscription, so prioritise by how much each privileged account could touch, not by the recommendation count.

The insurance arithmetic is one-sided. The remediation is engineering time plus an optional, bounded investment in PIM if you want the tightening to hold. The downside of leaving it is the documented cost of an insider incident or an account takeover that reached Owner: data exfiltration, resource destruction, ransomware staging, then breach notification, forensics, legal fees and reputational damage.

Sam is the finance partner supporting the platform team's ISO 27001 push. The security report lands with several identity and access findings across two older production subscriptions. The instinct is not to wave through a remediation budget; it is to ask what is actually behind each red finding. Removing a surplus Owner, revoking an external partner or deleting a blocked account's role assignment changes nothing on the Azure bill, so the spend question is narrow: the only optional cost in the whole capability is Microsoft Entra ID Governance licensing if the team decides to adopt Privileged Identity Management to keep the set tight, and that is a deliberate choice, not a remediation line.

Sam asks the team to map each privileged account to a real, current person and need. The platform admins group is legitimate and stays. Two named engineers genuinely run the subscription. One external partner finished their integration last year and should be removed. One account belongs to a leaver, blocked in Entra but never cleaned up. The list is reframed on the risk register: the external partner and the blocked leaver are high expected-loss items to remove today at zero Azure cost, and the Owner count comes back under three by consolidating the rest behind a single group with just-in-time activation. The finance pack reads: 'Every finding closes at no incremental Azure spend; the only decision with a cost attached is whether we license PIM to make the tightening durable, and that is a governance investment we recommend, not a remediation bill.'

The cost model here is asymmetric in a way that is rare for security work. Tightening privileged access costs nothing in Azure spend, and leaving it broad creates an unbounded tail risk. Each surplus, external or dormant Owner is an account whose compromise or misuse could affect the entire subscription, and while the probability per account is low, the probability across many privileged accounts over years is not. The Owner role is the worst case precisely because its blast radius is everything the subscription contains.

The documented cost of an insider incident or an account takeover that reached Owner includes mandatory breach notification within tight regulatory windows, forensics and legal fees that routinely run into six and seven figures, the operational cost of rebuilding a compromised environment, and customer churn. Against that, the remediation is engineering time plus an optional, bounded investment in Privileged Identity Management if you want the tightening to hold. The finance role is to attach expected loss to each privileged account, weighted by what it could touch, so the work is prioritised by risk rather than by the order the report lists it.

Privileged access is the category of risk where a single compromised or disgruntled account can affect everything at once. An Owner can read every secret, delete every resource and grant themselves or others permanent access. When too many people hold that role, when outsiders hold it, or when accounts that should be gone still hold it, the report shows this as a scatter of separate findings across the estate.

The leadership question is not 'are we compliant today?' It is 'how many identities could take total control of each subscription right now, and do we actually trust and need every one of them?' The defensible end state is a small, named, current, internal set of privileged accounts per subscription, with standing Owner replaced by just-in-time access and stale or external assignments removed.

None of this is a cost decision. Tightening privileged access is essentially free in Azure terms. It is a governance decision about whether the keys to each subscription are held by the smallest trustworthy set by design, or whether the list has simply grown because nobody was watching it.

After a peer company suffered an incident traced back to a contractor account that kept full control long after the engagement ended, the CEO asked the obvious question at the next review: how many people, and which outsiders, can take total control of our subscriptions right now? The honest answer at the time was that nobody could say precisely, because Owner had been granted ad hoc over years and the list had never been pruned.

The team's response was to stop treating access as a per-finding cleanup and start treating it as a guardrail. They listed every Owner on every subscription, removed the external and blocked accounts, consolidated the legitimate admins behind a single group, and moved standing Owner to just-in-time activation through Microsoft Entra Privileged Identity Management with recurring access reviews. The next time the CEO asked the question, the answer had changed from 'we are not sure' to 'a named, internal group of three, none standing, all activated on demand and reviewed every quarter, with no external or dormant accounts holding privilege anywhere.' That shift, from a list that grew by accident to a set that is the smallest it can be by design, is the one-line confidence signal this capability delivers, and it costs nothing in Azure spend to reach.

Nearly every catastrophic cloud incident that involved a single account taking total control came back to the same root cause: a privileged assignment that should not have still existed, or should never have been that broad. Tightening privileged access is the capability that makes that root cause structurally difficult, and just-in-time activation through Privileged Identity Management makes it close to impossible, because there is no standing Owner credential to steal in the first place.

The cost of getting this wrong is large and well documented, while the cost of fixing it is essentially engineering time plus an optional governance licence. 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.