Access Control

Block Legacy Authentication Safely

For Microsoft 365 teams: retire older password-only sign-in paths without unexpectedly breaking scanners, applications, or administrator access.

Content review: 2026-09-22 · Estimated effort: Medium

Priority and effort are editorial starting points, not calculated risk or mandatory deadlines. Adapt to business impact, vendor instructions, available licenses, and applicable obligations. Test changes before broad rollout.

Before you start

Before starting: identify the tenant administrator, change approver, recovery route, and affected service owners. Record current settings and test protected emergency access. Never remove your only working administrator access.

Put it into practice

  1. In Microsoft Entra, open Monitoring & health > Sign-in logs. Review both interactive and non-interactive user sign-ins, filtering Client app for legacy authentication. Inventory older mail clients, scanners, scheduled jobs, and applications; ask owners about infrequent jobs that the available logs may miss.
  2. Move dependencies to vendor-supported modern authentication or a documented alternative. A protocol name alone is not proof of Basic authentication: some mail protocols support OAuth. Test sending, receiving, and scheduled workflows before retiring the old path; do not use app passwords as an MFA replacement.
  3. Choose the available enforcement route. Security defaults includes legacy-auth blocking at no additional cost, but is a tenant-wide package without per-user exceptions or report-only rollout. Review all its effects and prepare all users before enabling it under Entra ID > Overview > Properties > Manage security defaults. Do not disable existing protections merely to follow this guide.
  4. If licensed for Conditional Access, use Microsoft's linked legacy-auth blocking policy instructions. Start in Report-only, inspect the impact, then enforce for a pilot and expand. Report-only does not block anything. Follow the emergency-access guidance, document any necessary exclusions with an owner and expiry, and separately review workload identities not covered by user policies.
  5. Verify: confirm the intended policy is enforcing, supported clients still work, and relevant legacy attempts are denied for the expected reason. Use only an authorized test account if a live test is needed; never re-enable a retired protocol to test it. No observed legacy sign-ins alone is not proof of a block. Record scope, date, exceptions, and evidence without credentials.
  6. If disruption occurs: use the tested recovery route and diagnose the specific dependency. Prefer a supported replacement; any temporary policy exception needs approval, compensating protection, an owner, and a removal date. Do not switch off MFA tenant-wide to restore one device.

Make a start

Tools and templates

Start with what you already have. “Included” means part of an existing eligible product or subscription, not a free standalone service. Options reviewed 2026-09-22; check current vendor terms before choosing.

Start without another software subscription

Review Entra security defaults, which does not require a premium license, and inventory dependencies with the free change worksheet.

Where this stops: Security defaults is tenant-wide. Selective policy customization may need Conditional Access licensing; a different authenticator cannot make an old application support modern authentication.

See the official sources and eligibility details below. Free software can still require equipment, storage and staff time.

Microsoft Entra security defaults

No additional premium license; requires a Microsoft Entra tenant

In Entra ID > Overview > Properties, review Manage security defaults. Inventory dependencies and protect emergency access before changing enforcement.

Limits: An on/off tenant-wide package, not a per-user pilot policy. Conditional Access customization requires at least Entra ID P1; do not disable existing protections to use this option.

Your information: Your existing Microsoft tenant processes identities, sign-ins and policy information. Never upload tenant exports to this website.

Official instructions: Microsoft Entra security defaults ↗

Download a working template

Free to download and adapt for your team. Open CSV files in Microsoft Excel using your existing Office license; Markdown files open in a text editor such as Notepad. Save an Excel Workbook (.xlsx) copy if you add formatting. These are manual worksheets, with no macros, scoring or automatic verification.

Fictional worked example

Illustration only. This is not a customer story, lab result, or evidence that your environment is protected. Replace the example entries and record your own observations.

A team discovers an older scanner that sends invoices through business email.

Use the Security change and verification record template.

What to enter before testing

Change ID
EXAMPLE-LEGACY-01
Service and scoped recipients
Invoice scanner and its sending service
Prerequisites and recovery access checked
Pending: confirm supported authentication and recovery owner
Actual test results
Not tested

How to verify

Inventory the scanner dependency with its owner and follow current provider instructions for a supported sending method. Use a harmless authorized test message and inspect available sign-in or mail evidence before changing enforcement. Verify legitimate sending and the intended block separately.

If the result is unexpected

If invoices stop sending, use the pre-agreed business fallback and investigate the dependency. Pause broader rollout; avoid restoring legacy authentication across the tenant. Record any approved temporary exception with an owner and expiry.

Save completed worksheets privately. They can describe security gaps, systems and people. Do not include passwords, recovery keys or confidential message content. This site does not receive your edits; a cloud editor or synced folder may send them to its provider.

Sources and review approach

Original small-team guidance with selected NIST CSF 2.0 alignments, not an official crosswalk or a complete framework implementation. These instructions are a starting point, not a claim of testing in your environment.

  • NIST CSF 2.0: PR.AA-03: strengthening authentication paths
How this guidance is prepared