Practical guide · Identity and access
Multi-factor authentication and Conditional Access: the non-negotiable baseline
MFA turned on somewhere in an admin console and MFA actually enforced on every account are not the same protection. This guide details the specific controls a monthly cadence should check, beyond the general question of who holds access.
The decision to make
This guide helps a team verify whether its authentication and Conditional Access controls are genuinely enforced, or merely switched on somewhere in a console.
MFA needs to cover everyone, including administrator accounts
An MFA rollout that skips service accounts, administrators, or a few “temporary” accounts leaves open exactly the door attackers target first. Recurring verification compares the list of active accounts against the list of accounts genuinely subject to an MFA requirement, with no undocumented exception.
Conditional Access policies replace one-size-fits-all rules with risk-based ones
A baseline policy can require MFA for everyone, then layer in more precise rules: blocking a sign-in flagged as high risk, requiring a compliant device to reach certain applications, or rejecting a token that is too old. Monthly review confirms these policies exist, are active, and apply to the right applications.
- A baseline policy applied to every user
- Additional rules for sensitive roles
- A log of exceptions and their justification
Trusted locations need to stay accurate
A policy that trusts “the office IP address” loses its value if that address changed after a move or an internet provider switch, or if guest Wi-Fi shares the same exit point as the corporate network. Monthly review confirms the trusted-location list still matches the real office setup.
Legacy authentication remains a forgotten back door
Older mail protocols - POP, IMAP, authenticated SMTP - often cannot present an MFA challenge at all, which makes them a preferred target once a password leaks somewhere else. Blocking legacy authentication should be actively confirmed, not just assumed because a policy exists somewhere.
SSO for line-of-business apps closes off orphaned passwords
An accounting application, a supplier portal, or an industry tool connected through its own separate password sits completely outside Microsoft 365 MFA. Connecting these applications to the tenant’s single sign-on, where possible, brings that entry point back under the same oversight as everything else.
A simple matrix for assigning the work.
| Situation | Owner | Cadence | Useful evidence |
|---|---|---|---|
| MFA on every active account | M365 owner | Reviewed every cycle | List of justified exceptions |
| Conditional Access policies | M365 owner + leadership | Agreed review | Active, tested policies |
| Legacy authentication | M365 owner | Ongoing verification | Blocking confirmed |
Decision checklist
What should be true before considering this area under control.
- MFA applies to every account, including administrators
- Conditional Access policies reflect sensitive roles
- The trusted-location list is current
- Legacy authentication is blocked and verified
- Critical line-of-business apps use the tenant’s single sign-on
Next step
Connect these controls to the broader access review.
Access hygiene covers accounts, guests, and roles more broadly; this guide zooms into the identity layer beneath it. Then use the assessment to see whether these controls have a clear owner in your organization.