Your MFA Is On. Is It Actually Covering You?
|

Your MFA Is On. Is It Actually Covering You?

The question you couldn’t answer

Your MFA is on. But if someone came for your tenant tonight, would it actually hold? And could you explain, out loud and in plain words, why? Those two questions separate the teams that are protected from the ones that only feel protected. On is easy. Covered is a different word, and the distance between them is where this piece lives.

I think about a security chief I’ll call Dana. Sharp, respected, ran the security program for a mid-sized firm. One afternoon a newer analyst was walking her through the environment and asked something simple. “Why do we still let the finance group sign in with a texted code?” Dana opened her mouth, and stopped. She’d signed off that MFA was on and told the board they were covered. Whether a texted code would hold against a real attack that night, she wasn’t sure.

A security leader stands behind a seated analyst at a monitor showing a sign-in dashboard with a green MFA ON label; her expression is uncertain as she studies it.

MFA, multifactor authentication, means a sign-in needs more than a password. At the executive level the job isn’t switching it on. It’s owning whether the kind you turned on would survive a real attack, proving it, and standing behind that answer to a board, an auditor, and an insurer. That’s the distance between “MFA is on” and “we’re covered.”

Let me say the respect part first. If security is yours to answer for, whatever your title says, you carry a weight most people never see. You set the standard. When something gets through, it’s your name that comes up, sometimes on the filing. That’s real work, and plenty of firms your size never get anyone to carry this at all. But setting the standard is one job. Knowing whether it survives contact with a real attacker is completely another. One job lives on a slide. The other lives in a policy that either holds or quietly leaks.

So here’s a belief that isn’t the fashionable take. To really ensure the standard, the person who owns it should stay close to the craft, the art and skill of it. You can’t vouch for what you can’t read. Anyone can look up what a control is. The flip side is being able to read the policies, predict what they will do, and catch what’s wrong in mere moments. That skill is the technology itself, and it’s the first thing we work on in our security coaching. Dive deeper: How to Read a Conditional Access Policy

So here’s your map. What “on” really has to mean now. Why the craft goes stale the day you stop tending it. And the answer you can put in front of a board, an auditor, or an insurer and defend.

“On” isn’t “covered”

“MFA is on” and “we’re covered” are not the same thing. On just means a second factor happens. It does not mean you’ll hold off a real attacker, and mistaking the one for the other is exactly where confident teams get caught. Being truly covered means that factor would survive the attack aimed at it. On is confidence. Covered is competence, and the earned confidence competence brings. Plenty of break-ins now walk straight through MFA that was technically on, because the method was one a fake page could relay or a stolen token could skip.

An executive alone in a dusk office looks up at a large glowing green checkmark and the word ON on a wall display, with city lights below through the glass.

Microsoft’s own finding is that turning on MFA blocks more than 99.9% of account-compromise attacks. But attackers read the same report. They stopped guessing passwords and started building fake sign-in pages that catch a texted code and pass it to the real site in real time, while you’re still looking at your phone. The second factor happened. It just happened for them too, at the same moment.

Not every second factor works this way. A texted code can be relayed. A passkey or a security key can’t, because it’s tied to the genuine site, with nothing to read out loud (or type) into the wrong place. Same word, very different outcomes. In our foundational coaching we walk a team up that ladder, from any-MFA to the phishing-resistant methods, so they can look at a sign-in and know which kind is standing behind it.

Two-column comparison of MFA switched on and attested versus MFA built to hold with phishing-resistant methods, risk-based prompts, and device-bound tokens.

This is where it gets personal. To buy cyber insurance, you sign a form promising certain protections are switched on, and MFA on your privileged accounts is almost always a requirement. You sign it. Then, after a ransomware attack, the insurer checks whether that promise was true. In one real case, a cyber insurance company called Travelers found it wasn’t. MFA was covering the firewall, but not the admin accounts the attacker used. So Travelers refused the claim and moved to cancel the policy. That’s the risk in a sentence. A control that’s on almost everywhere, but not on the account that got hit, is the gap an insurer finds after the loss, when it’s your name on the form.

The pain isn’t the breach. It’s learning, from the breach, that the green slide was wrong, in the room where you presented it. Show a control works, and the surprise goes away, and so does the dread that you attested to something you can’t back.

The craft that fades or compounds

Advanced MFA isn’t a switch you flip once. It’s a practice that has to be maintained and kept up. Attackers moved from beating the MFA prompt to stealing what comes after it, the token your app gets the moment you’ve proven yourself.

There’s an old idea worth borrowing. The word technology comes from two Greek pieces: tekhne, meaning art, craft, or skill, and -logy, the study of. So technology isn’t the gizmo or iPhone you hold in your hand. It’s not the AI agent or a tool. It’s literally the craft of putting what you know to work, and keeping that craft alive. Having a thing isn’t the same as applying it.

Two woodworking chisels on a workbench, one freshly honed and bright and the other dull and worn, with the word tekhne in gold.

Picture the engineer who set your MFA up two years ago and did a solid job. Then they moved on to the next fire, and nobody kept studying it. Meanwhile the attackers changed tactics. Today the attack of choice is token theft, and there are real answers for it: MFA that reacts to a risky sign-in instead of asking everyone the same question, a fresh prompt the moment someone opens something sensitive like a privileged-access vault (CyberArk) or a finance system (Dynamics), and token protection that ties the pass to the device it was issued to, so a stolen one is worthless anywhere else. None of this helps if the craft or skill quietly becomes stale.

This is the part I most want to land. A team that keeps studying this compounds, the way interest does. Small and steady, until one day they’re far ahead of the threat. They read a policy and catch the hole in seconds. They notice the quiet things, like an attacker who never beats your MFA at all, who signs in first on a brand-new account and registers their own phone as the second factor. Guarding that registration moment is its own skill, one we spend real time on, because MFA is only as strong as the moment someone sets it up. Stop studying, and the door drifts open while everyone believes it’s shut.

Diagram breaking the word technology into tekhne, art craft skill, plus logy, the study of, showing that a studied craft compounds and a neglected one decays.

The MFA You Can Prove

What good actually looks like isn’t a house nobody can break into. No such house exists. It’s a risk you chose on purpose, wrote down, and can defend, with the people who share that risk putting their names next to yours.

A defensible business MFA posture has a few defining properties worth committing to memory. The strongest methods sit on the highest-value accounts, your admins first, the accounts holding the highest privileges. Your Entra environment reacts when a sign-in looks wrong, instead of trusting a password that may already have leaked. The token handed out after sign-in is worthless if it’s stolen. And the accounts you had to leave out, the break-glass accounts every tenant keeps so a bad policy can’t lock everyone out, are deliberate and documented, not quietly forgotten. We work this entire baseline in coaching, exclusions and all, because the standard you attest to has to be true everywhere you claim it.

Here’s the part that feels good. Picture yourself a year from now. The board asks whether we’re covered, and you don’t hesitate or reach for hope. You show them. The insurance form doesn’t make your stomach drop, because every word on it is true and you can prove it. And when a newer analyst asks why something is set the way it is, you answer, in your own words.

One thing to do this week (homework)

  1. Pick one account, your own or a single admin.
  2. Trace it end to end.
  3. What method does it actually use?
  4. Would it survive a fake login page?
  5. Can you prove it’s on?

If any answer is a shrug, that isn’t necessarily a failure. It’s the first policy worth reading, and the start of getting the craft back, starting now.

Frequently asked questions

Q. Does turning on MFA mean we’re covered?

A. Not by itself. MFA blocks the large majority of password attacks, but “on” only means a second factor happens. Whether you’re covered depends on the method. A texted code can be relayed by a fake login page in real time. A passkey or security key can’t.

Q. Can MFA be bypassed?

A. Yes. Attackers use fake sign-in pages to relay your login codes in real time, and they steal the token you receive right after you sign in. Phishing-resistant methods and token protection are what shut those two paths down.

Q. Why do CISOs care about phishing-resistant MFA specifically?

A. Because attackers stopped guessing passwords and started relaying second factors through fake sign-in pages as they happen. Phishing-resistant methods, like passkeys, security keys, and Windows Hello, are tied to the genuine site, so a look-alike page gets nothing. For admin accounts, that difference is close to everything.

Q. Why do cyber insurance claims get denied over MFA?

A. Because the application attested MFA was protecting certain systems, and after a breach the insurer found it wasn’t there. If a control is on in most places but not the one that got hit, that gap can void the payout.

Q. Should a CISO know the technical side of MFA, or just set the policy?

A. You can delegate running the controls. But to stand behind the standard you own, and attest to it honestly, you need to read what you turned on and know whether it holds. Owning the outcome without knowing the craft is how an attestation drifts from reality.

Get expert guidance on Microsoft Entra Conditional Access and MFA

Glossary

MFA (multifactor authentication): a sign-in that needs more than a password, adding something you have, like a phone or a key, or something you are, like a fingerprint.

Phishing-resistant MFA: stronger methods, such as passkeys, FIDO2 security keys, and Windows Hello, tied to the genuine site so a fake page can’t reuse them.

Token / token protection: a token is a temporary pass your app gets after sign-in so you aren’t prompted on every click. Token protection binds it to your device, so a stolen one can’t be used elsewhere.

Break-glass account: a deliberately excluded emergency account, kept so a misconfigured policy can’t lock everyone out of the tenant.

Attestation: a statement you sign, on an insurance form or a customer questionnaire, that a control is in place. It has to be true and provable where you claimed it.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *