
Turning multifactor authentication on is not the same as requiring it. Most Microsoft 365 tenants we assess have MFA enabled and still have at least one sign-in path where a password alone is sufficient. That path is where the account takeover happens.
The short answer
Check three things this week: whether legacy authentication is blocked tenant-wide, whether every privileged role requires MFA, and whether your conditional access policies contain exclusions that were meant to be temporary. Any one of these left open makes the others largely decorative.
Enabled, registered, enforced
Three different states, routinely conflated.
Enabled means the capability exists in your tenant. On its own it changes nothing.
Registered means a specific user has set up a method. A policy requiring MFA only protects users who have registered one; unregistered users get prompted to enrol at the worst possible moment, and are often excluded to unblock them.
Enforced means every account and every sign-in path requires it, with exclusions that are deliberate, documented and monitored.
Organisations describe themselves as having MFA when they mean the first. Attackers care only about the third.
Legacy authentication is the usual gap
Protocols such as IMAP, POP, SMTP AUTH and older Exchange ActiveSync clients cannot present a multifactor challenge. They accept a username and password and grant access.
This is why password spray campaigns target them first. An attacker with a valid credential does not attempt the path you secured — they choose the one that never had a challenge to begin with.
Blocking legacy authentication tenant-wide is the single highest-value identity control available to most organisations, and it is free. Create a conditional access policy targeting all users, with client app conditions set to Exchange ActiveSync and other clients, and grant control set to Block.
Run it in report-only mode first. Some multifunction printers, scan-to-email configurations and older line-of-business applications still rely on basic authentication, and finding those before you block is considerably less disruptive than finding them afterwards.
Report-only is not a state to leave a policy in
Report-only is the correct way to pilot a policy. It is also where policies go to be forgotten.
We regularly find tenants with a well-designed conditional access policy — sensible scope, correct controls, clear naming — sitting in report-only months after the pilot ended. The portal shows a list of policies. The tenant enforces none of them.
Review each report-only policy against its impact data. Move it to enabled, or delete it. A policy that enforces nothing while appearing to protect you is worse than no policy, because it stops anyone asking the question.
Exclusions that outlive their reason
Every conditional access policy accumulates exclusions. A contractor who needed access from an unmanaged device. A service account that broke when the policy applied. An executive travelling somewhere the location condition blocked.
Each was reasonable at the time. Few are reviewed afterwards.
Audit the exclusion lists on every enabled policy. For each excluded account, ask who approved it, when, and whether the reason still applies. The answer is often that nobody remembers.
One exclusion should survive that review: the emergency access account.
The break-glass account
A misconfigured policy, an expired MFA method or a federation outage can lock every administrator out of the tenant simultaneously. A cloud-only account excluded from conditional access is the way back in.
Configure it properly: a long random passphrase stored offline, no MFA dependency on a device or phone number, excluded from all conditional access policies, and an alert on any sign-in it makes. If that account signs in and you did not expect it, that is an incident.
Without one, recovery from a bad policy means a Microsoft support case and hours of downtime.
Privileged roles deserve stricter treatment
An administrator account without enforced MFA is the shortest path from a phished password to full tenant control.
Create a policy scoped to directory roles — Global Administrator first, then Exchange, SharePoint, User and Security Administrator — requiring multifactor authentication with no exclusions beyond the break-glass account.
While you are there, count your Global Administrators. If you cannot name each one and justify why they hold it, you have too many. Two to four is the range most organisations should be in.
A checklist you can work through this week
- Is legacy authentication blocked tenant-wide, in an enabled policy rather than report-only?
- Does every privileged directory role require MFA?
- How many conditional access policies are enabled, and how many are report-only or disabled?
- What accounts are excluded from each enabled policy, and who approved each exclusion?
- Does an emergency access account exist, and does it alert on sign-in?
- What proportion of your users have actually registered a strong authentication method?
- How many Global Administrators do you have, and can you justify each?
Frequently asked questions
Do security defaults give us enough protection?
Security defaults enforce MFA registration and block legacy authentication, which puts a small tenant ahead of many larger ones. They are not configurable, though — you cannot exclude a break-glass account or apply different rules to administrators. Most organisations outgrow them and should move to conditional access, but turning them off without replacing them is a common and serious mistake.
Will blocking legacy authentication break anything?
Sometimes. Multifunction printers using scan-to-email, older mail clients, and line-of-business applications with hardcoded credentials are the usual casualties. Run the policy in report-only mode for a week and review the sign-in logs to identify what is still using legacy protocols before enforcing.
Is SMS-based MFA acceptable?
It is considerably better than nothing and worse than the alternatives. SMS is vulnerable to SIM swap and interception. Prefer an authenticator app with number matching, and phishing-resistant methods such as FIDO2 keys or Windows Hello for Business for privileged accounts.
Does the Data Privacy Act require MFA?
The Data Privacy Act requires reasonable and appropriate technical security measures rather than naming specific controls. Access control is explicitly among the measures the National Privacy Commission expects, and multifactor authentication is the accepted baseline for it. In a breach investigation, the absence of enforced MFA on administrative accounts would be difficult to defend as reasonable.
How do we know what our tenant actually enforces?
Read the policies rather than the intentions. Every item on the checklist above can be verified directly in Entra ID, and the answers frequently differ from what the organisation believes to be true.
Where to start
Onprem2Cloud IT Solutions Co. is a Microsoft Cloud Solution Provider based in Muntinlupa City, serving businesses and government agencies across Metro Manila and beyond. We run cloud security posture assessments for Microsoft 365 and Azure environments — conditional access and MFA coverage, legacy authentication, privileged role review, application permissions, guest access, and the gap between written policy and enforced configuration.
Findings are mapped to the CIS Microsoft 365 Foundations Benchmark and ranked by exploitability, with specific remediation steps. Get in touch to discuss an assessment of your tenant.
What's happening
Our latest news and trending topics
