Somewhere right now, an employee’s password from an old, unrelated website breach is sitting on a criminal forum, bundled with millions of others, waiting to be tried against corporate logins across the world. Whether that stolen password can actually get anyone into your systems often comes down to a single setting buried deep in your Azure tenant, one that few business leaders have ever personally looked at.
One Policy Standing Between a Leak and a Breach
Conditional access policies decide what happens after someone enters a correct username and password: whether they are waved through, challenged for a second factor, or blocked outright based on their location, device, or risk signals. Configured well, this single layer can render a stolen password almost worthless to an attacker holding it. Left on default settings, it can quietly let that same password walk straight through the door unchallenged. Most business owners have never seen this policy screen, let alone reviewed what it actually permits across their organisation.
Many organisations assume that because they use Azure Active Directory, security is handled automatically in the background. In reality, thorough Azure pen testing frequently uncovers conditional access policies that were switched on years ago and never revisited since, still allowing logins from any device, anywhere in the world, with no second check at all applied.
Why Defaults Are Rarely Enough
Azure’s default posture leans toward accessibility, which makes sense for a platform trying to get new tenants up and running quickly without early friction, but it is not the same thing as a security-first posture. Left unadjusted, an employee could log in from an unmanaged device on the other side of the world at three in the morning and nothing would flag it as unusual, because nothing was ever configured to consider it unusual in the first place. Tightening the policy afterwards is usually a matter of hours, not weeks, once someone actually identifies where the gaps sit.
This is the gap William Fieldhouse points to time and again when reviewing client tenants across different sectors.
“I tested a finance firm last year where the conditional access policy existed on paper but had never actually been enforced across every application in the tenant, so their most sensitive finance system was the one exception quietly left wide open. A stolen password would have worked perfectly on that single system.”
— William Fieldhouse, Director of Aardwolf Security Ltd
That single exception is the kind of gap that never shows up in a compliance checklist, because on paper the policy exists and reads correctly to anyone reviewing the document. It takes someone actively testing every application against the policy, not just reading the policy itself, to find the one door that was quietly left off the list entirely. The finance system in question was, unsurprisingly, the one an attacker would have wanted most.
Make the Stolen Password Irrelevant
You cannot stop employee passwords from appearing in breach dumps years from now, no matter how much training you provide. But you can make sure that a correct password alone is never enough to get an attacker into your systems. Review your conditional access policies against every application in your tenant, not just the obvious ones, and work with the best pen testing company you can find to confirm the gaps are actually closed rather than merely assumed closed on paper. A tenant that looks compliant on paper can still leave the most valuable system in the building entirely unguarded.