Require Microsoft Entra authentication

Moving a service onto Microsoft Entra authentication costs nothing in Azure spend. Adding a SQL Entra administrator, generating SSH keys, disabling a Cosmos DB account key or switching Synapse to Entra-only does not change your bill. The cost sits entirely in coordination: the application teams whose connection strings and scripts still use a password or account key have to switch to a managed identity or token before you can safely turn the local path off, and that is engineering time, not licence spend.

Frame each failing recommendation as a line on the risk register rather than a compliance checkbox. A Cosmos DB account whose primary key is embedded in a dozen services carries a far higher expected loss than an empty test database, yet both surface as a single red finding. A SQL server holding production customer data with no Entra admin is a different order of risk from a sandbox instance. Map the failures to the data and the access behind them and prioritise by exposure, not by recommendation count.

The insurance arithmetic is one-sided. The remediation is engineering time plus a bounded migration of clients off static secrets. The downside of leaving it is the documented cost of a leaked-credential breach: a single account key or SQL password in a leaked config grants standing access that nobody can revoke without rotating it everywhere, and the directory has no record of who used it.

Sam is the finance partner supporting the platform team's ISO 27001 push. The security report lands with nine identity findings spread across SQL servers, a Synapse workspace, two Cosmos DB accounts and several Linux VMs in two older subscriptions. The instinct is not to wave through a blanket remediation budget; it is to ask what is actually behind each red finding. Provisioning a SQL Entra admin, generating SSH keys or disabling a Cosmos DB account key changes nothing on the Azure bill, so the spend question is narrow: the only real effort is migrating the applications and scripts that still use a password or account key onto a managed identity, and that is engineering time, not licence cost.

Sam asks the team to map each failing service to the data and the clients behind it. One SQL server holds production customer records with no Entra admin, one Cosmos DB account hands out a primary key embedded in a dozen services, the Synapse workspace still has its local SQL admin enabled, and the rest are sandbox and test resources. The list is reframed on the risk register: the customer SQL server and the heavily-shared Cosmos DB key are high expected-loss items to close first, the Synapse workspace is a bounded change once its admin is moved to Entra, and the test resources are low-value drift to sweep up. The finance pack reads: 'Every finding closes at no incremental Azure spend; the only real cost is the engineering time to move a handful of applications off static secrets, and that work also removes credentials nobody can currently revoke.'

The cost model here is asymmetric in a way that is rare for security work. Moving a service onto Microsoft Entra costs nothing in Azure spend, and the only real effort is migrating the applications that still use a static secret onto a managed identity. Leaving the local credential enabled creates an unbounded tail risk: every standing key or password is a credential that could leak and grant access nobody can centrally revoke.

The documented cost of a leaked-credential breach includes mandatory notification within tight regulatory windows, forensics and legal fees that routinely run into six and seven figures, and the difficulty of even proving what was accessed when the credential left no identity trail. Against that, the remediation is engineering time plus a bounded client migration. The finance role is to attach expected loss to each failing service, weighted by how widely its secret is shared and how sensitive its data is, so the work is prioritised by risk, not by the order the report lists it.

Identity is the perimeter now. A service that still trusts a local password, account key or standalone certificate is a door the directory cannot see through: no record of who connected, no conditional access, no way to switch the credential off the moment a person leaves or a secret leaks. The report shows this as a scatter of separate findings across virtual machines, databases and clusters.

The leadership question is not 'are we compliant today?' It is 'when someone leaves the company tomorrow, or a connection string leaks, can we cut their access in one place?' The defensible end state is that every service authenticates through Microsoft Entra, local credentials are disabled, and the few exceptions are documented with an owner.

None of this is a cost decision. Putting Entra in front of these services is essentially free in Azure terms. It is a governance decision about whether access is centrally controlled by design or scattered across static secrets that each have to be remembered, rotated and trusted.

After a departing engineer's old database connection string turned up still working months later, the CEO asked the obvious question at the next review: when someone leaves, can we actually cut their access everywhere? The honest answer at the time was that it depended, because several production services still authenticated with SQL logins, account keys and SSH passwords that the directory had no visibility of and could not revoke on its own.

The team's response was to stop treating these as scattered findings and start treating them as one guardrail: identity, not secrets. They provisioned a Microsoft Entra administrator on every SQL server, switched the Synapse workspace to Entra-only authentication, disabled the account key on the Cosmos DB databases whose clients could use a managed identity, moved the Linux fleet to SSH keys, and put Service Fabric client access behind Entra. Then they assigned Azure Policy to flag any new resource that came up trusting a local credential. The next time the CEO asked the question, the answer had changed from 'mostly, but it depends on the service' to 'yes, access runs through Entra, so disabling someone's directory account cuts them off everywhere at once.' That shift, from secrets nobody can centrally revoke to identities the directory governs, is the one-line confidence signal this capability delivers, and it costs nothing in Azure spend to reach.

Nearly every major cloud breach that involved stolen access came back to a credential that should not have still worked: a key or login that outlived the person who created it, with no central way to switch it off. Requiring Microsoft Entra authentication is the capability that removes that root cause, because access becomes an identity the directory governs rather than a secret that lives forever.

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