Microsoft 365 identity and security readiness: what is actually enforced now

Most Microsoft 365 tenants that come to us for review were configured correctly once, and then drifted for four years. That is not negligence. It is what happens when a platform changes faster than the review cycle that governs it. Over the last two years Microsoft has been steadily converting things that were recommendations into things that are enforced, and the gap between "we turned MFA on" and "we are ready for what is now mandatory" is where most of the remaining risk sits.

Start with what is actually enforced, because the dates matter. Mandatory multifactor authentication for Azure sign-in rolled out in two phases. Phase 1 began in October 2024 and covers the Azure portal, the Microsoft Entra admin center and the Microsoft Intune admin center, for any create, read, update or delete operation. The Microsoft 365 admin center followed in February 2025. Phase 2 began on 1 October 2025 and extended enforcement to the Azure CLI, Azure PowerShell, the Azure mobile app, infrastructure-as-code tooling and the Azure Resource Manager REST API, for create, update and delete operations only. Read operations are exempt. Microsoft allowed tenants with complex environments to postpone Phase 2, but the latest available start date under that arrangement was 1 July 2026. If your organisation took the extension, it has now expired.

The detail that catches people is break-glass accounts. Microsoft's guidance is unusually direct about this: emergency access accounts are also required to sign in with MFA once enforcement begins, and the system enforcement applies to all user accounts regardless of whether they are a break-glass account, an administrator with an eligible role, or a user you deliberately excluded in a Conditional Access policy. The classic emergency-access design — a cloud-only account with a long random password, excluded from every policy, printed and sealed in a safe — no longer works as written. Microsoft's own recommendation is to move those accounts to a passkey (FIDO2) or to certificate-based authentication, both of which satisfy the requirement. If nobody has touched your break-glass accounts since 2023, that is the first thing to check, not the last.

The second surprise is service accounts that are really user accounts. If you have automation — a scheduled task, a deployment script, a legacy integration — signing in as a licensed human user against Azure Resource Manager, it is in scope for Phase 2 and it will begin failing on create, update and delete operations. Workload identities, meaning managed identities and service principals, are not impacted by either phase. The fix is therefore a migration rather than a setting, and migrations take longer than the outage window you get if you discover the problem reactively.

Related, and easy to miss: the OAuth 2.0 resource owner password credentials flow is fundamentally incompatible with MFA. Applications built on username-and-password token acquisition will throw exceptions once MFA is enabled in the tenant, and Microsoft has deprecated those APIs across the .NET, Go, Java, Node.js and Python libraries. If anyone in your estate built an integration that stores a username and a password in environment variables, that integration now has a deadline rather than a backlog item.

Now the licensing conversation nobody enjoys. Conditional Access requires Microsoft Entra ID P1. Microsoft 365 Business Premium includes it, which covers a large share of small and midsized organisations. But risk-based Conditional Access — the policies that key off sign-in risk and user risk — requires Microsoft Entra ID Protection, which is a P2 feature. A great deal of published Conditional Access "best practice" quietly assumes P2 and never says so. Confirm which tier you actually hold before you design a policy set, or you will spend a week specifying something that will not deploy.

If you do not have P1, security defaults are available to all customers and are enabled by default. This is worth stating plainly because it cuts against our own commercial interest: for a thirty-person business with no legacy authentication, no on-premises directory and no compliance obligation beyond ordinary duty of care, security defaults plus a short review may be a complete and appropriate answer. You do not need a consulting engagement to switch on something that is already on. What you may need is someone to confirm nothing has been quietly switched off.

When you do need real policy, Microsoft's own model is a useful skeleton because it is tiered rather than binary. The Zero Trust identity and device access guidance defines three levels — Starting point, Enterprise and Specialized security — and varies the controls across them. At the starting point, MFA is enforced when sign-in risk is medium or high, Intune app protection applies, and you require a compliant or domain-joined PC while still permitting personal phones and tablets. At the enterprise level, MFA enforcement extends down to low sign-in risk and compliant devices are required across the board. At the specialized level, every new session requires MFA. Most organisations do not need one policy set. They need two: a sane default, and a stricter one for the accounts whose compromise would hurt most.

One warning from that same guidance deserves repeating, because the failure mode is spectacular and self-inflicted: do not create policy sets that apply to all applications. A policy that blocks all apps can lock administrators out of the Microsoft Entra admin center, and exclusions cannot be configured for some important endpoints such as Microsoft Graph. Roll policies out one application group at a time, deploy every one of them in report-only mode first, and keep the What If tool open while you do it. It is also worth internalising that Conditional Access is enforced only after first-factor authentication has completed. It is a policy engine, not a front door, and Microsoft is explicit that it was never intended as an organisation's frontline defence against denial-of-service-shaped attacks.

On the authentication method itself, the direction of travel is not ambiguous. Passkeys built on FIDO standards use origin-bound public-key cryptography and require local user interaction, which gives them verifier impersonation resistance: the authenticator will only release its secret to the relying party the passkey was registered with, not to an attacker impersonating that party. That property is precisely what defeats the relay and credential-harvesting attacks that render SMS codes and emailed one-time passcodes so much weaker than their presence in a compliance checklist suggests. Microsoft reports, from its consumer Microsoft account population, that 99% of users successfully register synced passkeys, and that sign-in completes in about 3 seconds against 69 seconds for a password plus traditional MFA. Those are Microsoft's figures, drawn from consumer accounts rather than managed enterprise tenants, and we would treat them as directional rather than as a business case you can put in front of a finance director.

What we do not recommend is buying FIDO2 security keys for the entire company as a first move. Hardware keys are the right answer for highly regulated environments and for privileged users, and Microsoft says as much — but they carry real costs in equipment, training and helpdesk load, and the account-recovery path for a lost key is the part almost nobody rehearses before they need it. Synced passkeys are a reasonable default for most of a workforce. Reserve device-bound keys for the accounts where you would also want to enforce attestation, and go into that decision knowing that enforcing attestation excludes synced passkeys by design. That is a deliberate trade-off, not a defect, and it should be made consciously per group rather than swept across a tenant.

The most common way a readiness effort goes wrong is sequencing. Teams write the target policy set first and then discover the inventory problems — the service account nobody owns, the excluded break-glass account, the integration that predates the current team — during enforcement, when the pressure to add "just one exclusion" is at its highest. Exclusions added under that pressure become permanent. Do the inventory first. It is the duller half of the work and it is most of the job.

If you would rather anchor the conversation in a standard than in a vendor's documentation, NIST Special Publication 800-63B revision 4, Digital Identity Guidelines: Authentication and Authenticator Management, was published final in July 2025 and defines technical requirements across three authenticator assurance levels. It is written for federal information systems, but it remains the cleanest available vocabulary for arguing precisely about what "strong authentication" means when a customer, an insurer or an auditor asks you to define it.

The checklist below is what we work through on a readiness review. The order is deliberate: inventory before policy, policy before enforcement, enforcement before hardware. If you would rather have a second opinion than a project, the scoping call is 15 minutes, and a fair share of them end with us telling you that you have already solved the parts that matter.