An attacker logs into your Microsoft 365 tenant at 03:47 using a finance manager's credentials. The session sails through MFA. No alerts fire. By the time anyone notices, a CEO impersonation email has gone to your largest client with new bank details. Forensics later confirms the MFA was "working" — the user approved a push notification, half-asleep, at 03:46. Your authentication control did exactly what it was configured to do. It just wasn't configured to stop this.
This pattern repeats across our incident engagements. MFA is deployed, ticked off the cyber insurance questionnaire, and assumed to be a finished control. It rarely is. The NCSC's 2024 guidance on phishing-resistant MFA, the FCA's continued focus on authentication weaknesses under PS21/3 operational resilience, and the rising volume of adversary-in-the-middle (AiTM) kits like Evilginx and Tycoon 2FA mean SMS codes and push notifications no longer constitute strong authentication. They constitute a speed bump.
Below are the seven configuration mistakes we see most often during Pyralink security reviews — and the specific remediations our consultants apply. If you operate Microsoft 365, Google Workspace, Okta, or any IdP, work through this list before your next audit.
Mistake 1: Treating Push Notifications as Phishing-Resistant
Push-based MFA — the "tap to approve" prompt on Microsoft Authenticator, Duo, or Okta Verify — is not phishing-resistant. It is phishing-vulnerable by design. Attackers using AiTM proxies steal the session token after the user approves the prompt. MFA fatigue attacks, where an attacker spams approval requests until the user taps yes, succeeded against Uber in September 2022 and continue to land monthly.
The NCSC's published position is unambiguous: only FIDO2/WebAuthn security keys, platform authenticators (Windows Hello for Business, Apple Passkeys), and certificate-based authentication qualify as phishing-resistant. Number matching on push helps with fatigue attacks but does nothing against AiTM token theft.
What to do: enrol all privileged accounts on FIDO2 hardware keys (YubiKey 5 series, Feitian, or Token2). For general users, deploy passkeys via Windows Hello for Business or platform authenticators. Treat push as a transitional control with a documented sunset date — not a destination.
Mistake 2: Leaving Legacy Authentication Protocols Enabled
Modern Conditional Access policies only apply to modern authentication endpoints. If POP3, IMAP, SMTP AUTH, or legacy EWS are still enabled in your Microsoft 365 tenant, attackers bypass MFA entirely by authenticating through these protocols with stolen credentials.
Microsoft disabled basic auth for most protocols in October 2022, but SMTP AUTH remains on by default for new tenants and existing exceptions persist in most environments we audit. Run Get-CASMailbox across your tenant. You will likely find shared mailboxes, service accounts, and "we'll fix it later" exceptions from 2021 still active.
The fix is two-step: disable SMTP AUTH tenant-wide via the Exchange admin centre, then create a Conditional Access policy blocking legacy authentication for all users. Monitor sign-in logs for 30 days to catch any service accounts that break, then migrate them to OAuth 2.0 or Graph API.
Mistake 3: Excluding "Break-Glass" Accounts Without Compensating Controls
Every well-run tenant has emergency access accounts — break-glass accounts excluded from Conditional Access in case MFA infrastructure fails. The problem: most organisations create them, document the password in a password manager, and never look at them again.
These accounts are the single highest-value target in your directory. They have Global Administrator rights and no MFA. We have found break-glass credentials stored in shared OneNote files, Confluence pages indexed by Microsoft Search, and on one memorable occasion, a sticky note on a server room rack.
Configure break-glass accounts properly: store credentials in two physical safes at different sites, split between two custodians, with sign-in alerting via Azure Monitor that pages the on-call CISO the moment authentication occurs. Test the procedure quarterly. Anything less and you have a backdoor, not a contingency.
Mistake 4: Conditional Access Without Device Compliance
MFA proves who is signing in. It does not prove what they are signing in from. An attacker with valid credentials and a stolen MFA token on a personal laptop with no EDR, no disk encryption, and no patching looks identical to your finance director on her corporate device.
Conditional Access policies that require "MFA" without also requiring "compliant device" or "Intune-managed device" leave a gap an AiTM attacker drives a lorry through. The MFA implementation best practice we apply on every engagement: require both MFA and device compliance for access to email, SharePoint, and any line-of-business application handling personal data under UK GDPR.
For BYOD scenarios, App Protection Policies via Intune enforce containerisation on iOS and Android without managing the whole device. This is the route most professional services firms should take.
Mistake 5: No Session Lifetime Controls
Default Microsoft 365 refresh tokens last 90 days. Once an attacker steals a session token via AiTM, they can replay it for weeks without ever triggering re-authentication. Default settings serve attacker convenience, not your security posture.
Configure sign-in frequency controls in Conditional Access. For privileged roles, force re-authentication every 4 hours. For standard users accessing sensitive applications, set 24 hours. Enable Continuous Access Evaluation (CAE) so token revocation propagates in near-real time when a risky sign-in is detected.
Pair this with token protection (in preview at time of writing for Windows desktop clients) which binds refresh tokens to the device. A stolen token becomes useless off the original endpoint.
Mistake 6: Ignoring Service Accounts and Workload Identities
Human MFA gets the budget. Service accounts get forgotten. Yet in cloud environments, workload identities — service principals, managed identities, API keys — often outnumber human users 10 to 1 and frequently hold higher privileges.
You cannot put MFA on a service principal. You can, and must, do the following: rotate client secrets on a defined schedule (90 days maximum), prefer certificate authentication over secrets, scope permissions to the minimum required, and monitor sign-in logs for anomalous service principal behaviour. CloudAuditX surfaces over-privileged service principals and stale credentials across Azure, AWS, and GCP in a single view — the kind of cross-cloud visibility that manual auditing rarely catches.
Mistake 7: No Path to Passwordless
Every MFA deployment that stops at "password plus second factor" is a halfway house. The password remains the weakest link — phishable, reusable, breach-replayable. A serious passwordless strategy removes the password from the authentication flow entirely.
The mature target state: Windows Hello for Business or platform passkeys as primary authentication, FIDO2 hardware keys as backup, and certificate-based authentication for high-assurance scenarios. Microsoft Entra ID supports this today. Google Workspace supports passkeys natively. Okta supports FIDO2 across its full product line.
The migration takes 6 to 12 months for a typical mid-market organisation. Start with privileged users, expand to IT and finance, then general staff. Disable password authentication entirely once enrolment crosses 95%. This is the destination the NCSC, CISA, and every serious identity practitioner is pointing toward.
How Pyralink Helps
Pyralink Innovation Ltd, led by Michael Adedeji (CISM, CISA, CC, MSc Data Science), runs identity and authentication reviews as part of broader cybersecurity programmes. Our consultants have implemented phishing-resistant MFA across financial services, legal, and SaaS environments, and we hold £5M professional indemnity insurance.
Our engagements typically combine three elements: a technical configuration review using CloudAuditX to surface gaps across Microsoft 365, Azure, AWS, and GCP; a policy and governance layer aligned to ISO 27001 certification requirements (specifically Annex A.5.17, A.8.5, and A.8.2); and ongoing oversight through our fractional vCISO service from £497 per month. For deeper reading on adjacent controls, browse our insights or run the free compliance scanner to benchmark your posture.
MFA done badly creates false assurance. MFA done well shrinks your attack surface to a sliver. The seven mistakes above are where we focus first — because they are where attackers focus first.