How to Set Up a YubiKey for Microsoft 365 in Microsoft Entra ID
Phishing-resistant sign-in is no longer only for large enterprises. A YubiKey can give Microsoft 365 accounts a much stronger line of defence than passwords, SMS codes, or push prompts alone.
This guide walks through how to how to set up a YubiKey for Microsoft 365 using Microsoft Entra ID, formerly Azure Active Directory. It covers the admin setup, user registration, testing, and the checks to make before rolling it out across an organisation.
What a YubiKey for Microsoft 365 does & setting Up
A YubiKey is a physical security key used to prove a user’s identity during sign-in. It supports modern authentication standards such as FIDO2 and WebAuthn, which are designed to resist phishing.
Instead of typing a one-time code or approving a mobile notification, the user verifies sign-in by inserting the key into a device or tapping an NFC-enabled key against a compatible phone or tablet. Many YubiKey models also require the user to touch the key, which proves physical possession.
For Microsoft 365, a YubiKey can be used with services such as:
Outlook
Teams
OneDrive
SharePoint
Microsoft Entra joined devices
Other Microsoft cloud apps that use Entra ID sign-in
The main benefits are clear:
Protection against phishing
FIDO2 sign-in is bound to the legitimate service. A fake sign-in page cannot simply capture and reuse the authentication response.
Stronger account security
Attackers need the physical key, the correct sign-in flow, and often the user’s PIN.
A simpler sign-in experience
Once registered, users can sign in with a key instead of juggling codes and phone prompts.
Support for passwordless authentication
YubiKeys can help reduce reliance on passwords, especially for high-risk accounts.
Less dependence on mobile phones
This is useful for shared work devices, staff without reliable mobile coverage, or users who do not want to use a personal phone for work authentication.
Before you start
You will need a few things in place before you enable security keys.
Make sure you have:
A Microsoft 365 tenant
Microsoft Entra ID
A compatible YubiKey, such as a YubiKey 5 Series key
Administrator access to Microsoft Entra
A supported browser, such as Microsoft Edge or Google Chrome
A user account for testing
A plan for recovery if a key is lost
For a first rollout, avoid enabling the policy for everyone at once. Start with a pilot group so you can test registration, sign-in, recovery, and support processes.
Good pilot users include:
Directors
Finance staff
Global Administrators
Privileged role holders
Users with access to sensitive information
These accounts are often targeted first during phishing campaigns, so they are useful places to start, provided you manage the rollout carefully.
For emergency access accounts, do not rely on a single authentication method. Keep break-glass accounts protected, documented, and excluded from policies only where necessary.
Step 1. Create a pilot group in Microsoft Entra
Before switching on FIDO2 security keys, create a dedicated group for testing.
In the Microsoft Entra admin centre:
Go to `https://entra.microsoft.com`.
Open `Identity`.
Go to `Groups`.
Select `New group`.
Choose a security group.
Give it a clear name, such as `FIDO2 Security Key Pilot`.
Add your test users.
Save the group.
Using a group keeps the deployment controlled. If something does not work as expected, you can adjust the policy without affecting the whole organisation.
For early testing, include at least one standard user and one privileged account. This helps confirm the experience works across different account types and access levels.
Step 2. Enable FIDO2 security keys in Microsoft Entra
Next, enable FIDO2 security keys as an authentication method.
Sign in to:
`https://entra.microsoft.com`
Then go to:
`Protection` → `Authentication methods` → `Policies`
Select:
`FIDO2 security key`
Set the policy to enabled.
Under the target settings, choose the pilot group you created. Do not select all users unless you are ready for a full deployment.
Review the available configuration options. Depending on your tenant and licensing, you may see settings such as:
Allow self-service setup
Users can register their own security keys from the security info page.
Enforce attestation
This can help verify that the key is a genuine supported device. Some organisations leave this off during early testing, then tighten it later.
Key restrictions
These can limit which security key models are allowed. This is usually managed using Authenticator Attestation GUIDs, often called AAGUIDs.
For a pilot, keep the setup simple unless your security policy requires strict key restrictions from day one. Once you have confirmed that registration and sign-in work, you can narrow the supported devices.
Click `Save`.
Step 3. Allow users to register authentication methods
Users need permission to register authentication methods before they can add a YubiKey to their account.
In Microsoft Entra, check the registration settings for authentication methods and self-service security info. In many tenants, users can manage their security information through Microsoft’s sign-in security portal.
Users can usually register at:
`https://mysignins.microsoft.com/security-info`
They may also reach the same area by going to their Microsoft account security information page after signing in.
For a smooth pilot, tell users what they need before they start:
Their YubiKey
Access to their Microsoft 365 account
An existing MFA method, if already required
A supported browser
A few minutes without interruption
If users do not already have MFA set up, you may need to provide a Temporary Access Pass. This lets them complete registration securely without relying on a weaker method.
Step 4. Register the YubiKey as a user
The user now registers the key to their own Microsoft 365 account.
From a supported browser, the user should:
Go to `https://mysignins.microsoft.com/security-info`.
Sign in with their Microsoft 365 account.
Select `Add sign-in method`.
Choose `Security key`.
Select the key type, usually `USB device` or `NFC device`.
Insert the YubiKey or prepare it for NFC.
Follow the browser prompt.
Create a security key PIN if asked.
Touch the YubiKey when prompted.
10. Give the key a recognisable name.
11. Finish the registration.
The name matters. A label such as `YubiKey USB-C primary` is more useful than `Security key 1`, especially when a user later adds a backup key.
If the browser asks for permission to access the security key, the user should allow it. The prompt comes from the browser and operating system, not from the YubiKey itself.
Step 5. Test Microsoft 365 sign-in with the YubiKey
After registration, test the key before relying on it.
Ask the user to open a private browsing window or use a browser where they are not already signed in. Then go to a Microsoft 365 service such as:
`https://www.office.com`
The sign-in flow will vary depending on your tenant settings. The user may see an option such as `Sign in with Windows Hello or a security key`, or they may enter their username first and then choose the security key method.
A typical test looks like this:
Enter the Microsoft 365 username.
Choose the security key sign-in option.
Insert or tap the YubiKey.
Enter the security key PIN if prompted.
Touch the key.
Confirm access to Microsoft 365.
Test the apps your users actually depend on, not just the web portal. Check Outlook, Teams, OneDrive and SharePoint. If your organisation uses device sign-in or conditional access rules, test those flows as well.
The goal is simple: the user should be able to sign in reliably without needing a password or SMS code, where your policy allows it.
Step 6. Add Conditional Access rules where needed
Enabling YubiKeys gives users a strong authentication method, but Conditional Access decides when that method is required.
For high-risk accounts, you can create a policy that requires phishing-resistant authentication. In Microsoft Entra, this can be handled through authentication strengths where available.
A careful approach is to require stronger authentication for:
Global Administrators
Privileged role administrators
Finance and payroll systems
Sensitive SharePoint sites
Access from unmanaged devices
Access from unfamiliar locations
When building Conditional Access policies, use report-only mode first where possible. This helps you see the effect before enforcing the policy.
Avoid locking users out by accident. Exclude emergency access accounts as required by your internal policy, and document why those exclusions exist.
Step 7. Register a backup key
Every user who depends on a YubiKey should have a recovery plan. For high-risk or privileged users, a second key is strongly recommended.
A backup key helps when:
The primary key is lost
The key is damaged
A user changes device type
The user is travelling
NFC or USB access is not available on the current device
The backup key should be registered to the same account and stored securely. For administrators, many organisations keep backup keys in a controlled location, such as a safe or managed IT store.
Do not share one security key between users. Each key should map to a specific person and account.
Step 8. Document the user process
A YubiKey rollout works best when users know exactly what to expect.
Create a short internal guide covering:
Which key model users will receive
How to register the key
What to do if the browser prompts for a PIN
How to sign in to Microsoft 365 with the key
How to report a lost or stolen key
Who to contact for help
Keep the instructions simple and visual. Many support calls happen because users are unsure whether to touch the key, enter the PIN, or wait for the browser prompt.
If you are deploying to non-technical staff, include screenshots from your own tenant. Microsoft wording can change over time, so keep the guide updated when the sign-in screens change.
Step 9. Roll out in phases
Once the pilot works, expand in stages.
A sensible rollout might look like this:
Phase | Users | Goal |
Pilot | IT, selected admins, test users | Confirm registration and sign-in |
High-risk users | Directors, finance, privileged roles | Protect targeted accounts |
Wider rollout | Departments or sites | Build support capacity gradually |
Standard policy | All suitable users | Make phishing-resistant sign-in normal |
During each phase, track common issues. Look for patterns such as unsupported browsers, confusion around PINs, missing backup methods, or problems with mobile devices.
Do not remove existing MFA methods too early. Keep fallback options available until users are confident and support teams know how to handle recovery.
Step 10. Know how to remove or replace a YubiKey
Lost keys need a clear process.
If a user loses a YubiKey, an administrator should review the account and remove the registered method if needed. Users may also be able to remove their own key from the security info page, depending on your tenant settings and whether they can still sign in.
The usual process is:
Verify the user’s identity through an approved internal process.
Remove the lost security key from the user’s authentication methods.
Issue and register a replacement key.
Review recent sign-in activity if there is any concern.
Confirm the user still has a working backup method.
For privileged accounts, treat a lost key as a security event. The key alone should not be enough for an attacker to sign in, but you still need to respond quickly.
Common setup problems to check
If registration or sign-in fails, check the basics first.
The browser is not supported
Use Microsoft Edge or Google Chrome. Some older browsers or locked-down environments may not support the required WebAuthn prompts.
The user is not in the enabled group
Confirm the FIDO2 policy targets the user or a group they belong to. Group membership changes may take time to apply.
The key type is not allowed
If you enabled key restrictions, confirm the YubiKey model is permitted.
The user cannot complete MFA during registration
Provide a Temporary Access Pass or another approved registration method.
The device blocks USB or NFC
Some managed devices have restrictive security settings. Test on the same device types your users will use day to day.
Conditional Access is forcing a different method
Review the sign-in logs in Microsoft Entra. They can show which policy applied and why the sign-in failed.
What success looks like
A successful deployment is not just a registered YubiKey. The real test is whether users can sign in securely, recover safely, and get help when something goes wrong.
By the end of the setup, you should have:
FIDO2 security keys enabled in Microsoft Entra
A pilot group configured
Users able to register their YubiKeys
Microsoft 365 sign-in tested with the key
Backup keys or recovery methods in place
Conditional Access policies reviewed
A clear lost-key process documented
Start with the accounts that attackers are most likely to target, then expand in phases. With the right setup, YubiKeys can make Microsoft 365 sign-ins both safer and easier to use.
Comments