Access Control
Implement Multi-Factor Authentication
Deploy MFA across all accounts, prioritizing privileged, remote, and externally-facing accounts to reduce credential-based attacks.
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 an administrator, supported methods, recovery procedures, and a protected emergency-access route. Never remove your only working administrator access.
Put it into practice
- Start with existing MFA capabilities in business email and important services. Record accounts, owners, licensing limits, and exceptions.
- Prefer phishing-resistant FIDO2/WebAuthn passkeys or security keys where supported. Ordinary approval prompts and one-time codes are not phishing-resistant; use available MFA while planning improvements.
- Pilot with a small group and test sign-in, lost-device recovery, and service dependencies. Prioritize administrators, email, and supported remote-access gateways, then expand on an agreed schedule.
- Review older authentication paths and exclusions that could bypass MFA. Test dependencies before blocking them and monitor emergency-account use.
- Verify: test a fresh sign-in on each important service and inspect enforcement rather than enrollment alone. Rehearse recovery without exposing recovery codes.
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
Microsoft Authenticator is free. For a Microsoft Entra tenant, review security defaults before buying advanced policies. A compatible free TOTP app is another option where the service and administrator allow it.
Where this stops: An app generates or approves authentication; the service must enforce it. Conditional Access customization requires eligible licensing. TOTP codes are not phishing-resistant and do not replace Microsoft push or passwordless methods.
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 ↗Microsoft Authenticator
Free mobile app; no app subscription required
Use Microsoft’s official download links and register through your service’s approved security settings. Test sign-in and recovery before removing an existing method.
Limits: Installing the app does not enforce MFA. Available methods depend on the service and policy; a free app does not grant Conditional Access licensing.
Your information: The app handles authentication secrets and account information. Review device protection and backup settings; never share registration QR codes or recovery codes.
Official instructions: Microsoft Authenticator ↗Bitwarden Authenticator: standalone app
Free standalone TOTP app for iOS and Android; no Bitwarden account required
For a service that permits third-party TOTP codes, follow its registration flow and test a code. Keep an approved recovery route before switching apps.
Limits: Not Microsoft push approval or passwordless sign-in, and TOTP is not phishing-resistant. Confirm your tenant permits software OATH. The password manager’s integrated code generator is a different feature with different licensing.
Your information: Local codes are stored on the device; vendor documentation describes a local unencrypted database. Protect the device and review OS cloud backups. Optional vault copying or syncing changes where secrets are stored. Restrict exports and never upload them here.
Official instructions: Bitwarden Authenticator: standalone app ↗Microsoft 365 MFA setup guidance
Use included tenant capabilities first; methods and advanced policies vary by license
Use the official setup instructions to identify your current enforcement route. Test an authorized sign-in and lost-device recovery rather than checking enrollment alone.
Limits: Security defaults and Conditional Access are different routes. A free authenticator app does not by itself enforce MFA; hardware keys may have a purchase cost.
Your information: Authentication and registration information is handled by your identity provider. Keep recovery codes out of worksheets.
Official instructions: Microsoft 365 MFA setup guidance ↗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.
- Security change and verification record (CSV) ↓
Plan one scoped change per row, including prerequisites, recovery, test expectations and actual results. An untested change is not a verified success.
- Administrator access review (CSV) ↓
Record roles, scope, justification, approval and the outcome of each review. Use identifiers appropriate for a restricted internal record.
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 wants to confirm that its existing MFA policy protects an authorized test account.
Use the Security change and verification record template.
What to enter before testing
- Change ID
- EXAMPLE-MFA-01
- Service and scoped recipients
- Microsoft 365: authorized test account
- Expected allowed and blocked behavior
- Authorized sign-in succeeds; access cannot bypass required MFA
- Actual test results
- Not tested
How to verify
Confirm the applicable enforcement policy, then perform an authorized fresh sign-in and inspect sign-in evidence. A missing prompt alone is inconclusive: an existing session or authentication method can satisfy MFA. Rehearse approved lost-device recovery.
If the result is unexpected
If access bypasses the intended policy or recovery fails, preserve working administrator access and investigate scope, exclusions and sessions. Do not disable tenant protections as a shortcut. Record the result and retest. Security defaults is tenant-wide, not a one-user rollout.
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: authentication, not identity proofing
- https://www.nist.gov/publications/nist-cybersecurity-framework-csf-20 ↗
- https://csrc.nist.gov/pubs/sp/800/63/b/4/final ↗