Your MFA Deadline Passed. Here’s What Still Isn’t Configured Correctly

The Microsoft multi-factor authentication deadline has passed, so your organisation must now be secure—right?

Not necessarily.

Microsoft began enforcing MFA for access to the Azure portal, Microsoft Entra admin centre and Microsoft Intune admin centre in October 2024, followed by the Microsoft 365 admin centre from February 2025. Phase 2 enforcement began rolling out from 1 October 2025 for Azure CLI, Azure PowerShell, mobile applications, Infrastructure as Code tools and control-plane API operations that create, update or delete resources. 

Those requirements are important, but they do not mean every user, application, device and sign-in route in your tenant is now protected correctly.

Microsoft’s mandatory enforcement focuses on particular administrative access paths. It does not automatically provide a complete identity-security design for your organisation. You may still have weak authentication methods, unmanaged devices, legacy protocols, poorly scoped Conditional Access policies, vulnerable service accounts and emergency access procedures that have never been tested.

This guide explains what businesses should check after the MFA deadline—and why seeing an MFA prompt is only the beginning.

Passing the Deadline Is Not the Same as Completing an MFA Project

The deadline changed the minimum authentication requirements for specific Microsoft management experiences.

It did not automatically:

• Create a complete Conditional Access strategy
• Protect every employee and guest account
• Replace weak MFA methods with phishing-resistant authentication
• Remove old authentication methods
• Secure user-based automation accounts
• Require managed devices
• Configure risk-based access
• Protect application registrations and workload identities
• Test emergency administrator access
• Train users to recognise advanced phishing
• Monitor stolen sessions and tokens

An organisation can therefore comply with Microsoft’s mandatory MFA enforcement and still have substantial identity risk.

A successful login prompt proves that MFA was requested in that particular situation. It does not prove that every access route is equally protected.

What Microsoft’s Mandatory MFA Enforcement Covers

Microsoft’s mandatory enforcement has been introduced in phases.

Phase 1

MFA became required for accounts accessing administrative portals, including:

• Azure portal
• Microsoft Entra admin centre
• Microsoft Intune admin centre
• Microsoft 365 admin centre

The rollout began gradually rather than switching on for every tenant simultaneously. 

Phase 2

From 1 October 2025, Microsoft began gradually extending MFA enforcement to accounts using:

• Azure CLI
• Azure PowerShell
• Azure mobile application
• Infrastructure as Code tools
• Azure SDKs
• Control-plane REST API endpoints

For these tools, the requirement applies to operations that create, update or delete Azure resources. Microsoft states that read-only operations are not covered by this Phase 2 requirement. 

This matters because businesses sometimes assume the change means MFA is now universally enforced across every Microsoft 365 and Azure interaction. It is not that simple.

Problem 1: MFA Is Required Only Where Microsoft Forces It

Your administrators may receive MFA prompts when they enter the Azure portal, but ordinary users could still access email, SharePoint, Teams or third-party applications without an organisation-wide MFA policy.

Microsoft recommends a baseline Conditional Access policy targeting all users and all resources, without application exclusions, and requiring an appropriate MFA authentication strength. Microsoft also recommends beginning in report-only mode before enforcement. 

Check whether your tenant relies only on Microsoft’s mandatory enforcement or whether you have intentionally configured MFA for:

• Employees
• Contractors
• Guest users
• Administrators
• Shared or resource accounts
• Remote workers
• Sensitive applications
• High-risk sign-ins
• Security information registration

An MFA requirement for administrators is not a substitute for protecting the rest of the workforce.

Problem 2: Your MFA Policy Does Not Target All Resources

A common Conditional Access mistake is targeting only familiar applications such as:

• Microsoft 365
• Exchange Online
• SharePoint Online
• Microsoft Teams

This can leave less obvious cloud applications outside the policy.

A stronger baseline generally targets all resources, then creates narrow, justified exceptions when necessary. Microsoft’s current guidance for an all-user MFA policy specifically recommends targeting all resources without application exclusions. 

Broad application exclusions can become permanent security gaps.

For every exclusion, record:

• Application name
• Business reason
• Technical owner
• Users affected
• Alternative protection
• Approval date
• Review date
• Planned removal date

“Something broke during testing” is not sufficient documentation for an indefinite exclusion.

Problem 3: You Are Still Using Per-User MFA

Older Microsoft environments may still use legacy per-user MFA settings.

Per-user MFA can provide protection, but it offers far less flexibility than Conditional Access. It does not make it easy to account for:

• Sign-in risk
• User risk
• Device compliance
• Network location
• Application sensitivity
• Authentication strength
• Session controls
• Guest access
• Emergency exclusions

Microsoft’s modern approach is to manage MFA through Conditional Access where licensing permits. For organisations without Microsoft Entra ID P1 or P2, Security Defaults can provide a basic Microsoft-managed security baseline. Conditional Access and Security Defaults are alternative approaches and are not intended to be used together. 

Review whether your tenant contains a mixture of:

• Per-user MFA
• Security Defaults
• Conditional Access
• Microsoft-managed policies
• Application-specific MFA controls

A fragmented configuration can produce inconsistent results that are difficult to troubleshoot or audit.

Problem 4: Users Have Registered Weak Authentication Methods

Not every MFA method provides the same protection.

Your users may still rely on:

• SMS codes
• Telephone calls
• One-time passcodes
• Push notifications
• Security questions or weak recovery processes

These methods are better than a password alone, but many remain vulnerable to phishing, social engineering, SIM-related attacks or adversary-in-the-middle techniques.

CISA recommends organisations plan a move towards phishing-resistant authentication based on FIDO or public-key cryptography. Microsoft identifies passkeys and FIDO2 security keys as phishing-resistant credentials that work only with the service for which they were registered. 

Your post-deadline review should ask:

• Which methods are enabled in the tenant?
• Which methods has each user registered?
• Are SMS and telephone authentication still permitted?
• Can administrators use phishable authentication methods?
• Are users encouraged to register passkeys?
• Are security keys available for high-risk roles?
• Are old methods removed after migration?

An organisation-wide MFA percentage of 100% can still conceal weak authentication.

Problem 5: Administrators Are Not Using Phishing-Resistant MFA

Administrative accounts should receive stronger protection than ordinary accounts.

Microsoft Entra provides built-in authentication strengths, including:

• Multifactor authentication
• Passwordless MFA
• Phishing-resistant MFA

Microsoft’s guidance for protecting administrators recommends the phishing-resistant MFA strength. 

Prioritise stronger methods for:

• Global Administrators
• Privileged Role Administrators
• Conditional Access Administrators
• Authentication Administrators
• Exchange Administrators
• SharePoint Administrators
• Security Administrators
• Finance system administrators
• Help-desk users who can reset credentials

Appropriate methods may include:

• FIDO2 security keys
• Device-bound passkeys
• Windows Hello for Business
• Certificate-based authentication
• Other methods accepted by your chosen authentication strength

A push notification should not be your highest-security administrative control merely because it meets the basic definition of MFA.

Problem 6: System-Preferred Authentication Has Not Been Reviewed

Users sometimes register several authentication methods but continue selecting the easiest rather than the strongest.

System-preferred authentication allows Microsoft Entra to prompt users with the strongest method they have registered. For example, a user with both SMS and a passkey can be prompted to use the passkey first. Microsoft manages this setting through the Authentication methods configuration. 

Review:

• Whether system-preferred authentication is enabled
• Whether you are using the Microsoft-managed state
• Which users or groups are excluded
• Whether users have stronger methods available
• Whether help-desk guidance matches the configured behaviour

System-preferred authentication does not replace Conditional Access or authentication-strength policies, but it helps move day-to-day sign-ins towards stronger registered methods.

Problem 7: Users Were Told to Register MFA, but Nobody Verified Completion

Sending an email that asks employees to configure Microsoft Authenticator is not a deployment plan.

Some users may have:

• Ignored the request
• Registered only a telephone number
• Set up the wrong account
• Changed phones without transferring access
• Registered one method with no backup
• Lost access to the original device
• Completed registration only after being forced during an urgent task

Use authentication-method reports to confirm what has actually been registered.

Microsoft Entra registration campaigns can also prompt targeted users to register Microsoft Authenticator or passkeys during sign-in. Administrators can control targeting and how often a user may postpone registration. 

A useful registration programme should include:

• Clear instructions
• Approved authentication methods
• A completion deadline
• Support for users who need help
• Backup or recovery arrangements
• Reporting
• Escalation for non-completion
• Removal of weak methods after migration

Problem 8: Legacy Authentication Is Still Available

Legacy authentication protocols may not support modern MFA properly.

These older sign-in methods can provide attackers with a route that bypasses the security experience users see in modern applications.

Security Defaults includes protections that require MFA registration, ensure administrators use MFA and block legacy authentication. Organisations using Conditional Access should create equivalent controls deliberately. 

Review sign-in logs for use of:

• Older mail clients
• POP
• IMAP
• Authenticated SMTP
• Legacy Office authentication
• Old mobile applications
• Unmodernised line-of-business applications

Do not disable a protocol blindly if an essential system still depends on it. Instead:

1. Identify the dependency.
2. Confirm the business owner.
3. Replace or update the application.
4. Create a temporary controlled exception only when unavoidable.
5. Monitor the exception.
6. Set a removal date.

Problem 9: User Accounts Are Still Running Automation

Microsoft’s Phase 2 enforcement has exposed a long-standing design problem: businesses often use normal employee-style accounts to run scripts, integrations and scheduled jobs.

Examples include:

• PowerShell scripts signed in as a user
• Azure CLI automation using stored user credentials
• Scheduled jobs tied to an administrator
• Infrastructure deployment tools using an employee account
• Shared automation accounts with passwords that never expire

Microsoft recommends migrating user-based service accounts to workload identities such as managed identities and service principals. Workload identities are treated differently from interactive user accounts and require their own security and governance. 

For every automated process, record:

• Identity used
• Authentication method
• Owner
• Permissions
• Credential location
• Credential expiry
• Applications accessed
• Business impact if it fails
• Replacement plan

The wrong response is to weaken MFA so an old script keeps running.

The correct response is to modernise the identity used by the automation.

Problem 10: Service Principals and Workload Identities Are Ignored

Moving automation away from user accounts is important, but service principals and managed identities are not automatically safe.

They can still be overprivileged, poorly monitored or dependent on long-lived secrets.

Review:

• Application registrations
• Enterprise applications
• Service principals
• Managed identities
• Certificates
• Client secrets
• Federated credentials
• Assigned roles
• Unused permissions
• Sign-in activity

Conditional Access policies scoped to users do not automatically control service-principal activity. Microsoft provides Conditional Access for workload identities for scenarios that require policies targeting service principals. 

Remove unused application credentials and replace stored secrets with managed identities or workload identity federation where supported.

Problem 11: Conditional Access Policies Were Enabled Without Report-Only Testing

A rushed MFA rollout can create lockouts and business disruption.

Microsoft recommends using report-only mode to evaluate how Conditional Access policies would affect real sign-ins before enforcement. 

A proper rollout should include:

1. Create the policy in report-only mode.
2. Review affected sign-ins.
3. Investigate exclusions and failures.
4. Test with pilot groups.
5. Confirm emergency access.
6. Communicate the change.
7. Enable the policy in stages.
8. Monitor failures after enforcement.

Report-only mode should not become a permanent parking place. A policy that has remained in report-only mode for a year is not protecting anyone.

Assign an owner and target date for every policy under evaluation.

Problem 12: Emergency Access Accounts Are Missing or Untested

Conditional Access mistakes can lock out the same administrators who need to repair them.

Microsoft recommends excluding emergency access, or break-glass, accounts from relevant Conditional Access policies so administrators retain a recovery route after misconfiguration. 

Emergency accounts should be:

• Cloud-only
• Separate from everyday administrator identities
• Strongly protected
• Monitored continuously
• Excluded only where genuinely necessary
• Stored securely
• Tested at defined intervals
• Used only during real emergencies

Testing should confirm:

• The credentials are available.
• The account can sign in.
• Alerts are generated.
• The account has the necessary recovery role.
• Responsible staff know the procedure.
• Any use is reviewed immediately.

An emergency account whose password nobody can retrieve is not an emergency-access strategy.

Problem 13: Administrators Use Their Privileged Accounts for Everyday Work

MFA does not justify using a Global Administrator account for normal email, browsing and document work.

Privileged users should ordinarily have:

• A standard account for everyday activity
• A separate administrative account
• Stronger authentication on the privileged account
• Limited administrative role assignments
• Just-in-time elevation where available
• No unnecessary mailbox or collaboration use on the admin identity

This reduces exposure to phishing, malicious attachments and session theft.

Also review how many permanent Global Administrators exist. Administrative access should reflect genuine operational responsibility, not seniority or convenience.

Problem 14: Unmanaged Devices Can Access Sensitive Data

An attacker who obtains a password and MFA approval—or steals a valid session token—may attempt access from an unmanaged device.

Conditional Access can evaluate device state and require controls such as:

• Compliant device
• Microsoft Entra joined device
• Microsoft Entra hybrid joined device
• Approved application
• Application protection policy
• Restricted browser session

Conditional Access is designed to evaluate factors such as identity, application, device configuration and network context before granting access. 

Sensitive applications may need stronger rules than general collaboration tools.

Examples include:

• Azure administration
• Payroll
• Finance
• HR records
• Customer databases
• Backup platforms
• Security portals
• Legal documents

MFA proves something about the authentication attempt. Device compliance adds confidence about the system requesting access.

Problem 15: No Risk-Based Policies Are Configured

A static MFA policy may treat every sign-in identically.

Microsoft Entra ID Protection can identify risky users and sign-ins, allowing Conditional Access policies to respond by:

• Requiring stronger authentication
• Requiring secure password change
• Blocking high-risk access
• Requiring a compliant device
• Triggering investigation

Microsoft recommends configuring risk-based Conditional Access policies while excluding emergency access accounts to prevent administrative lockout. 

Risk-based access can help detect situations such as:

• Unfamiliar sign-in properties
• Leaked credentials
• Suspicious IP addresses
• Atypical travel
• Malware-linked activity
• Unusual token use

It does not replace baseline MFA. It adds a response when the context becomes suspicious.

Problem 16: Security Information Registration Is Not Protected

An attacker who compromises an account may attempt to add:

• A new Authenticator registration
• Another phone number
• A security key
• A passkey
• An alternative recovery method

Once registered, the attacker may gain a more persistent route into the account.

Use Conditional Access to protect security-information registration. Depending on the organisation, you may require:

• MFA
• A managed device
• A trusted location
• A Temporary Access Pass issued through a verified process
• Strong help-desk identity proofing

Registration is a sensitive security event, not ordinary profile maintenance.

Problem 17: Help-Desk MFA Resets Are Too Easy

Technical controls can be undermined by a weak support process.

Attackers may contact the help desk and claim:

• They lost their telephone.
• Their Authenticator app stopped working.
• They urgently need access while travelling.
• Their security key was damaged.
• Their manager has already approved the reset.

A secure reset process should not rely solely on information easily found in email, social media or company websites.

Possible controls include:

• Manager confirmation through a known channel
• Identity verification against approved records
• Video or in-person checks
• Temporary Access Pass with short validity
• Notifications to the user’s existing contact methods
• Separate approval for privileged users
• Detailed audit logging
• Follow-up review

The strongest MFA method is only as secure as the procedure used to replace it.

Problem 18: MFA Prompts Are Still Vulnerable to Phishing

Conventional MFA can be defeated when users are tricked into approving the attacker’s session.

Common examples include:

• Adversary-in-the-middle phishing
• Device code phishing
• MFA fatigue
• Fake support calls
• Token theft
• Malicious OAuth consent

Passkeys and FIDO2 security keys are phishing-resistant because they use cryptographic keys tied to the legitimate website or application rather than reusable passwords or codes. Microsoft describes passkeys as a significant security upgrade over phishable MFA methods. 

Your post-deadline roadmap should therefore move beyond the question:

“Does the user have MFA?”

Ask instead:

“Is the user required to use an authentication method that resists phishing?”

Problem 19: Sessions and Tokens Are Not Monitored

An attacker may steal an authenticated session token after MFA has already succeeded.

This means identity monitoring must continue after the initial sign-in.

Review whether your security team can detect and respond to:

• Unusual session locations
• Token replay
• New inbox rules
• Suspicious OAuth consent
• Unfamiliar devices
• Large downloads
• New authentication methods
• Abnormal administrative activity
• Sudden external forwarding
• Risky sign-ins

The incident-response team should know how to:

• Revoke active sessions
• Revoke refresh tokens
• Reset credentials
• Remove malicious authentication methods
• Remove suspicious application consent
• Investigate mailbox rules
• Isolate affected devices
• Preserve evidence

Changing the password alone may not be sufficient when an attacker already holds an active token.

Problem 20: Guest Accounts Are Outside the Strategy

External guests can access:

• Teams
• SharePoint
• Shared documents
• Project workspaces
• Business applications

Review whether guest access requires MFA and whether the authentication strength is suitable for the data involved.

Also check:

• Inactive guests
• Completed contractors
• Old suppliers
• Expired projects
• Guests with broad group membership
• Anonymous sharing links
• External users with administrative roles

Guest access should be time-limited where possible and reviewed regularly.

Problem 21: Authentication Methods Are Enabled for Everyone

The Authentication methods policy should be deliberate.

Do not assume every method should be enabled tenant-wide.

Review access to:

• SMS
• Voice calls
• Microsoft Authenticator
• Temporary Access Pass
• Passkeys
• FIDO2 security keys
• Certificate-based authentication
• Email one-time passcodes for guests

Use pilot groups before broad rollouts.

For privileged accounts, consider a dedicated group with stronger permitted methods and Conditional Access authentication-strength requirements.

Problem 22: Your MFA Deployment Has No Recovery Design

Users will:

• Replace phones
• Lose devices
• Forget PINs
• Damage security keys
• Leave employment
• Travel without their normal equipment

A recovery design should include:

• More than one approved method where appropriate
• Spare security keys for critical users
• Verified help-desk processes
• Temporary Access Pass procedures
• Emergency administrative access
• Device replacement instructions
• Rapid offboarding
• Monitoring of method changes

Convenient recovery must not become a security bypass.

Problem 23: Nobody Owns the MFA Configuration

Identity security often falls between:

• Internal IT
• Managed service provider
• Security team
• Microsoft 365 administrator
• HR
• Compliance
• Department managers

Assign named owners for:

• Conditional Access
• Authentication methods
• Privileged accounts
• Guest access
• Emergency accounts
• Registration campaigns
• Workload identities
• Sign-in monitoring
• Incident response
• User communication

Without ownership, exclusions and temporary fixes tend to remain indefinitely.

A Practical Post-Deadline MFA Audit

Use this checklist to review your environment.

Coverage

• Is MFA required for all users?
• Are guests included?
• Are all resources targeted?
• Are administrative interfaces protected?
• Are sensitive applications subject to stronger controls?

Authentication Methods

• Which methods are permitted?
• Which methods are registered?
• Is SMS still widely used?
• Are voice calls enabled?
• Are passkeys or security keys available?
• Is phishing-resistant MFA required for administrators?
• Is system-preferred authentication configured?

Conditional Access

• Is there a baseline all-user MFA policy?
• Are policies in report-only mode unnecessarily?
• Are application exclusions documented?
• Are emergency accounts excluded correctly?
• Are device-compliance requirements used?
• Are risk-based policies configured?
• Is security-information registration protected?

Legacy and Automation

• Is legacy authentication blocked?
• Do old mail clients still connect?
• Are user accounts running scripts?
• Have automation accounts moved to workload identities?
• Are service-principal permissions reviewed?
• Are old secrets and certificates removed?

Operations

• Are sign-in logs reviewed?
• Can active sessions be revoked quickly?
• Are OAuth applications audited?
• Are mailbox rules monitored?
• Is there an account-compromise playbook?
• Are help-desk reset procedures secure?
• Are emergency accounts tested?
• Are users trained against advanced phishing?

A Sensible Improvement Plan

First 30 Days

• Confirm mandatory MFA enforcement status.
• Inventory users without registered methods.
• Review permitted authentication methods.
• Create or validate emergency accounts.
• Review all Conditional Access policies.
• Identify broad exclusions.
• Find user identities used for automation.
• Block obvious legacy authentication dependencies after testing.

Next 60 Days

• Require MFA for all users and all resources.
• Move the baseline policy through report-only and pilot stages.
• Require phishing-resistant MFA for administrators.
• Launch a registration campaign.
• Begin migrating automation to managed identities or service principals.
• Configure risk-based policies where licensed.
• Protect security-information registration.

Next 90 Days

• Extend passkeys or FIDO2 to high-risk users.
• Require compliant devices for sensitive applications.
• Review workload identities and application permissions.
• Test account-compromise response.
• Test emergency accounts.
• Review guest access.
• Remove obsolete exclusions and weak methods.
• Establish regular identity-security reporting.

Final Thoughts

The MFA deadline was a milestone, not the finish line.

Microsoft’s mandatory enforcement has raised the minimum security level for important administrative access paths, including portals, command-line tools and Azure management operations. That is valuable—but it does not replace a properly designed identity-security programme. 

Your environment may still contain:

• Users outside the MFA policy
• Weak authentication methods
• Legacy protocols
• User-based service accounts
• Overprivileged workload identities
• Broad policy exclusions
• Unmanaged device access
• Unprotected guests
• Weak recovery procedures
• Administrators using phishable MFA

The question is no longer simply whether MFA is enabled.

The better questions are:

• Who is protected?
• Which applications are covered?
• Which authentication methods are allowed?
• Which devices can connect?
• Which exceptions remain?
• How quickly can compromised sessions be revoked?
• Are administrators using phishing-resistant authentication?

MFA remains essential. Correct configuration determines whether it becomes a meaningful security control or merely another box that was ticked before a deadline.

Is Your Microsoft 365 MFA Configuration Actually Complete?

Hamilton Group can help review what Microsoft’s mandatory MFA enforcement does—and what it still leaves for your organisation to configure.

Our experts can help you:

• Audit MFA registration and coverage
• Review Conditional Access policies
• Remove weak or unnecessary authentication methods
• Deploy passkeys and FIDO2 security keys
• Protect administrator and finance accounts
• Block legacy authentication
• Migrate user-based automation accounts
• Secure service principals and workload identities
• Configure risk-based access
• Protect security-information registration
• Test emergency access accounts
• Build identity-compromise response procedures

Visit hgmssp.com, call Hamilton Group on 0330 043 0069, or book a meeting with one of our experts to assess your Microsoft 365 identity security.