Most Microsoft 365 security guides cover the same list. Multi-factor authentication for all users. Block legacy authentication. Configure anti-phishing policies. Use Microsoft Secure Score as a benchmark. These are still correct. But 2026 has introduced enough changes to the platform that following last year’s hardening checklist will leave you with gaps that didn’t exist before.
This post covers what’s actually changed, the things most hardening guides don’t address, and a practical priority order for UK businesses that haven’t had an independent review of their tenant configuration.
Why multi-factor authentication is no longer the answer by itself
For years the standard advice was simple: enable multi-factor authentication and the risk of account compromise drops dramatically. Microsoft’s own data supports this, and it remains true for the most common attacks. But it is no longer the whole picture.
The attack that has become dominant against Microsoft 365 tenants doesn’t try to bypass multi-factor authentication. It waits until the user has successfully completed it. An adversary-in-the-middle proxy sits between the user and Microsoft, captures the session token once authentication has passed, and replays it from the attacker’s location. The user sees a legitimate login screen, completes their authentication prompt, and everything looks normal. The attacker uses the captured session token to log in from somewhere else.
Multi-factor authentication verifies identity at the moment of sign-in. It does not protect the session that follows. An attacker who steals a valid session token after authentication has completed can use it without triggering another authentication challenge, because they're not signing in again. They're continuing a session that already passed.
This is why the hardening conversation in 2026 is primarily about three things: phishing-resistant authentication that cannot be intercepted, Conditional Access policies that evaluate the session continuously rather than just at sign-in, and ensuring that a stolen session token provides access to as little as possible.
What changed in 2026 that you need to know about
Conditional Access enforcement closes a gap in June 2026
From March 27, 2026, with phased rollout continuing through June 2026, Microsoft is fixing a specific Conditional Access enforcement gap. Previously, when a Conditional Access policy targeted all resources but included one or more resource exclusions, that policy was not enforced for certain types of sign-in (specifically, applications that request only OpenID Connect scopes or limited directory scopes). Users authenticating through those applications could bypass multi-factor authentication requirements entirely, even when the policy was configured to require it.
This was not a theoretical edge case. Any Conditional Access policy targeting “All cloud apps” with exclusions was potentially affected. Microsoft has notified affected tenants via the Microsoft 365 Message Centre.
If your Conditional Access policies include resource exclusions and you haven’t reviewed them since this change, you need to audit each policy now. Navigate to Entra admin centre, go to Protection, then Conditional Access, then Policies, and review every policy that targets All cloud apps with one or more exclusions listed. Some exclusions will now cause users to receive authentication challenges they weren’t getting before.
Passkeys are becoming the default
Since March 2026, Microsoft has been shifting Entra ID tenants towards passkey-first authentication, pushing passkey enrollment as the default over traditional authenticator application methods. Passkeys are phishing-resistant by design: they use cryptographic methods tied to the specific website and device, which means an adversary-in-the-middle attack simply doesn’t work against them. There’s nothing to steal in transit.
For UK businesses, the practical implication is that existing Conditional Access policies may interact unexpectedly with passkey enrollment flows. Some organisations with strict “All cloud apps” policies have found the passkey registration journey blocked by their own Conditional Access requirements. Review your authentication methods policy in Entra and check whether passkey profiles have been auto-created in your tenant.
Privileged Identity Management now supports Conditional Access on role activation
This is the change that matters most for administrator account security. Privileged Identity Management, Microsoft’s just-in-time privilege elevation system, now supports Conditional Access policy enforcement at the point of role activation. When an administrator requests to elevate their privileges, the system can now require fresh multi-factor authentication or phishing-resistant authentication before the elevation succeeds.
Previously, an attacker who had compromised an administrator account and stolen their session token could activate privileged roles without re-authenticating. That gap is now closeable. If you use Privileged Identity Management, configure a Conditional Access policy requiring re-authentication on role activation. It is currently opt-in.
The Copilot problem: why overpermissioned tenants just became more dangerous
If your organisation uses Microsoft 365 Copilot, or is evaluating it, there is a security dimension that most discussions understate. Copilot accesses everything the authenticated user can access across the tenant, emails, Teams conversations, SharePoint files, OneDrive documents, and surfaces content the user could technically reach but would never normally find.
The risk combines two existing problems. The first is that most Microsoft 365 tenants are overpermissioned: SharePoint sites with broad access, files shared via organisation-wide links, sensitivity labels inconsistently applied. Content that was theoretically accessible but practically obscure is now surfaceable in seconds.
The second problem is session token theft. Attackers using reverse-proxy phishing toolkits that capture session tokens after authentication are already targeting Microsoft 365. In a Copilot-enabled tenant, a stolen session token doesn’t just give access to one user’s inbox. It gives access to everything Copilot can reach, with the ability to prompt the system to find and surface confidential content at machine speed.
Audit your SharePoint external sharing settings, sensitivity label coverage, and Conditional Access session controls. A tenant that was "acceptably overpermissioned" before Copilot may be meaningfully risky after it. The configuration work needed before deploying Copilot is often more significant than the Copilot deployment itself.
The hardening priority order for 2026
If you’re approaching this from scratch, or reviewing configuration that hasn’t been updated in the past 12 months, work through these in order. Earlier items address higher-frequency and higher-impact risks.
Create break-glass accounts before touching anything else
A misconfigured Conditional Access policy can lock every administrator out of the tenant. It happens. Microsoft Support recovery from a full lockout is slow. Before making any configuration changes, create two emergency access accounts that are excluded from every Conditional Access policy, have long randomly-generated passwords, have multi-factor authentication registration that is not tied to the tenant itself, and are stored in a secure offline location.
Set up alerts on any sign-in from these accounts. They should never be used except in a genuine emergency. A sign-in from a break-glass account should trigger an immediate response.
Action: create two break-glass accounts. Exclude them from all Conditional Access policies. Store credentials offline. Alert on any sign-in activity.Block legacy authentication, completely
Legacy authentication protocols (IMAP, POP3, SMTP, older versions of Exchange ActiveSync) do not support multi-factor authentication. They authenticate with username and password only. An attacker with valid credentials can use these protocols to access email or other services and bypass every Conditional Access policy that requires multi-factor authentication, because the protocol itself cannot respond to the challenge.
The objection is always the same: printers, scanners, or older business applications that still use legacy authentication. Identify them, migrate them to modern authentication, then block legacy authentication universally. This should be one of the first policies created in any tenant.
Action: create a Conditional Access policy blocking legacy authentication for all users. Audit what currently uses legacy authentication before enabling and migrate those systems first.Require multi-factor authentication registration only from trusted locations
This is one of the most consistently overlooked controls in Microsoft 365 security, and one of the most impactful. An attacker who has stolen a password can register their own multi-factor authentication method to a Microsoft 365 account if registration is not restricted. Once they've registered their own authenticator, they own multi-factor authentication on that account: it becomes their tool, not yours.
Restricting multi-factor authentication registration to trusted locations (your office networks, or a named location that requires a compliant device) means a stolen password alone cannot be used to take over an account by adding a new authentication method.
Action: create a Conditional Access policy restricting "Register security information" to trusted named locations or compliant devices only.Audit every Conditional Access exclude list
This is where most hardening efforts fall apart over time. Good policies with accumulated exclusions. A user excluded during a proof-of-concept test. An application excluded because the vendor said it would break otherwise. A "temporary" location exception from three years ago. Every exclusion is a potential entry point.
The June 2026 enforcement change means some exclusions that previously had no effect (because the affected sign-in flows were outside the scope of enforcement) will now affect users. Review every policy before the enforcement date, understand what each exclusion is for, and remove any you cannot justify in writing.
Action: audit every exclusion in every Conditional Access policy. Document the owner, reason, and review date for each one. Remove anything that cannot be justified.Implement stricter controls for administrator accounts
Administrator accounts are the highest-value target in any tenant. They should not be protected by the same policies as standard users. A compromised administrator account gives an attacker full control of the tenant: they can create new users, remove multi-factor authentication requirements, grant permissions to applications, and extract everything.
At minimum: separate administrator accounts from day-to-day accounts, require phishing-resistant authentication (hardware security keys or Windows Hello for Business) for all administrator sign-ins, configure Privileged Identity Management for just-in-time elevation rather than permanent assignment, and enable the new Conditional Access enforcement on role activation so that elevation requires fresh authentication.
Action: separate admin accounts from daily-use accounts. Require phishing-resistant authentication for admin roles. Enable Privileged Identity Management with Conditional Access enforcement on role activation.Review SharePoint external sharing before deploying Copilot
The default SharePoint external sharing configuration in most tenants is set to allow sharing with anyone who has the link, without requiring authentication. This means any shared link from that tenant provides access to the document without any login. Most organisations don't realise this and have years of content in this state.
If you're running Copilot, or planning to, this becomes significantly more important. Copilot will surface content based on what the user can technically access. An overpermissioned tenant combined with a stolen session token is now a data exposure risk at a scale that wasn't possible before AI was integrated into the platform.
Action: review SharePoint Admin Centre external sharing settings. Restrict to authenticated sharing only unless there is a specific business requirement for anonymous links. Audit existing anonymous shared links and expire them.Audit logging: verify retention and that someone actually reads it
Audit logging in Microsoft 365 is enabled by default in most plans, but the default configuration is not the same as a properly configured logging setup. Retention on Business Premium is 90 days. Many investigations require looking further back than that. More critically: who reviews the logs? Defender for Microsoft 365 alerts firing into a shared mailbox that nobody monitors provide the appearance of detection without the substance of it.
Verify that audit logging is enabled, that retention meets your requirements, that sign-in logs are reviewed regularly, and that alerts have a defined owner who is responsible for acting on them. A logging system that generates alerts nobody reads is worse than no system, because it creates false confidence.
Action: verify audit logging is enabled and retention period meets your compliance obligations. Confirm every Defender alert type has a defined owner and response process.The pre-review checklist
Before booking an independent review of your Microsoft 365 tenant, or as a self-assessment starting point:
- Break-glass accounts exist and are excluded from all Conditional Access policies
- Legacy authentication blocked for all users via Conditional Access
- Multi-factor authentication registration restricted to trusted locations or compliant devices
- All Conditional Access exclude lists reviewed and documented, ideally before June 2026 enforcement change
- Administrator accounts are separate from day-to-day accounts
- Phishing-resistant authentication required for all administrator sign-ins
- Privileged Identity Management configured for just-in-time elevation
- SharePoint external sharing restricted to authenticated sharing only
- Sensitivity labels applied consistently, especially if Copilot is deployed or planned
- Audit logging retention verified and someone is designated to review sign-in logs and Defender alerts
- Passkey profile configuration reviewed if auto-created in your tenant since March 2026
Microsoft Secure Score is a useful benchmark, but treat it as a starting point rather than a measure of actual security. A high Secure Score does not mean a secure tenant. It means you’ve implemented the settings Microsoft recommends, which is not the same thing.
Our Microsoft 365 Security service covers tenant configuration review, Conditional Access design, Entra ID privilege audit, and the Copilot-readiness assessment that most businesses haven’t done before deployment. If you’d like an independent view of your current configuration, get in touch.