Raising security with organization-wide YubiKey (FIDO2) in Entra ID

Security policy changes reshape how people work—and often face resistance. Authenticator apps are familiar; Microsoft even offers a registration campaign to nudge users toward Microsoft Authenticator as their primary MFA. There’s no equivalent, out-of-the-box campaign for YubiKeys, and end-to-end implementation guidance is scattered. So why change at all—and isn’t Microsoft Authenticator good enough? 

Short answer: not if you want phishing-resistant, passwordless authentication at scale. This post explains why we enforce YubiKey (FIDO2) and exactly how to roll it out with Microsoft Entra ID, securely and with minimal friction. 

What is a YubiKey and why should we enforce its usage? 

A YubiKey is a small hardware security key that implements FIDO2/WebAuthn for strong, phishing-resistant authentication. Instead of push approvals or one-time codes, the key performs a public-key challenge–response that’s cryptographically bound to the site’s domain, making it resilient against Adversary-in-the-Middle (AiTM) attacks.  

At Hunt & Hackett, we enforce YubiKey use because it enables true passwordless sign-in, materially reduces push-fatigue/approval phishing, and removes shared secrets from the login flow. In our environment—managed devices and in-office onboarding—it delivers high assurance with low user friction and scales well across the organization. As a bonus, it also reduces help-desk load (fewer password resets). 

A look into our organization

To frame the rollout, here’s our baseline. Before enforcing YubiKey, employees authenticated to Microsoft Entra ID using the Microsoft Authenticator app. Access to our environment was limited to Intune-managed, compliant devices: company laptops and enrolled phones (including personal phones enrolled via Intune). Our fleet included both Dell laptops (Windows) and MacBooks, but we began migrating everyone to Mac to simplify device management. For this rollout we scoped YubiKey to company-managed MacBooks and enrolled phones only. Keeping to a single desktop OS reduced testing and support overhead. 

Phased rollout 

To ease adoption, we used a phased rollout: start with small pilot cohorts, fix issues, then expand before enforcing YubiKey org-wide. You can phase by (a) rolling out team-by-team and/or (b) enforcing YubiKey for specific high-risk actions first. For example, require YubiKey when requesting an Access Package or elevating a role in Privileged Identity Management (PIM). 

Quick checklist 

• Target pilot groups via Authentication methods (FIDO2) and expand membership over time 
• Use Conditional Access to require YubiKey for: 
  • PIM role elevation 
  • Access Package requests 
  • Sensitive apps/admin portals or off-network sign-ins 
• Monitor support tickets/telemetry; address blockers before the next phase

How to enforce YubiKey on Microsoft Entra ID 

Lifecycle management 

Before starting, it is important to note that while registering the Microsoft Authenticator App to your Microsoft account can directly be done after entering a username and password, registering the YubiKey requires you to additionally authenticate with MFA.  This makes the registration for YubiKey a bit more involved than that of the Microsoft Authenticator App, as we will require a form of bootstrapping authentication to enable any new employees to register the YubiKey.  

Another particularity of the YubiKey is that since it is a hardware token, we may encounter users who break it, lose it, forget it at home or block their PIN (a blocked YubiKey PIN cannot be recovered, and the user must reset the FIDO functionality on their YubiKey, and register it again from scratch). We can deal with these scenarios in two ways: either we can enable business continuity by allowing a secondary form of authentication for when a user’s YubiKey is unavailable, or we can choose to implement no alternative and decide a user’s work and access are interrupted until they obtain a working YubiKey again. To decide what to do, we need to weigh both the impact on the users as well as the security implications.    

As a hardware token, stock management of the YubiKey should also be considered. We need to have answers to the following questions: what type of YubiKeys should we order, how many do we keep in stock, how do we hand them out, how do we collect them when an employee offboards, and so on. Stock management responsibility may fall outside the scope of IT depending on how your organization is managed, so we omit these details from this blog post. But be aware that you need to inform the relevant teams in your organization to help you organize this! 

For our lifecycle management, we will be covering three core processes:

• Existing users – How to transition users from Microsoft Authenticator App to the YubiKey? 
• New users – What does onboarding day look like for a new user?
• Unavailable YubiKeys – What can we offer when a user’s YubiKey is lost/broken/forgotten/pin-blocked? 
  
  

Existing users 

The first lifecycle activity we will handle is the simplest – transitioning existing users to YubiKey. As mentioned earlier, registering YubiKey to your Microsoft account requires authenticating with an existing form of MFA. Existing users are already authenticating with the Microsoft Authenticator App, so we require only two actions from them: 

• Register their YubiKey on https://aka.ms/mfasetup: This will be their new, primary method of authentication. 
• Enable password-less sign-ins on their Microsoft Authenticator App: This will serve as a backup form of authentication for when their YubiKey is unavailable. 

Prior to requesting users to perform these two actions, we will enable YubiKey as an authentication method. This will allow our users to register and use YubiKey as an authentication method. Let’s start!  

Enabling YubiKey registration and authentication

At this stage, users will be able to register and authenticate with the models of YubiKey that we have permitted in our organization. It is time to instruct your users to register their YubiKeys and enable password-less sign-ins on Microsoft Authenticator App. While users are slowly registering their YubiKeys, you can monitor the progress with the Microsoft Graph API, by iterating through all users in your organization and checking whether they have registered a YubiKey yet with the fido2AuthenticationMethod API.  

Though users can now register and choose to authenticate with the YubiKey, it has not yet been enforced. Earlier, we discussed a phase-wise rollout to ensure all users are not immediately impacted by the sudden authentication switch from Microsoft Authenticator App to the YubiKey. Let’s implement this! 

Enforcing YubiKey authentication using conditional access policies

• Step 1: In Microsoft Entra ID, visit the Conditional Access | Authentication Strengths page. 
• Step 2: Create a + New authentication strength, which we will call “YubiKey”. From the authentication combinations list, select the Passkeys (FIDO2) option  and under Advanced options, add the AAGUIDs of all YubiKeys used by your organization. 
• Step 3: Our YubiKey authentication strength is now ready to be used in a conditional access policy. Let’s create a new one to enforce YubiKey authentication. In Microsoft Entra, go to Conditional Access | Policies and create a + New policy, which we will call “Enforce YubiKey”. The important configuration here is to select a Grant access control, where we will Require authentication strength: YubiKey.  
• Step 4: In line with our phase-wise rollout plans, we need to decide which resources we want to target this policy to. This is to ensure not all users struggle with their YubiKeys at the same time. You can choose to do this in two ways:  
  • Targeting subsets of users: For instance, you can start with enforcing the YubiKey for just the IT team, wait 2 weeks to see if there are any unanticipated issues and fix these, then enforce the YubiKey for the HR team, wait another 2 weeks, and so on until your entire organization is covered. Implement this as follows: 
    • Under Users, select Include > select users and groups and add only the security group containing the employees you want to target in this phase. 
    • Under resources, select all.  
  • Targeting user actions: This strategy entails enforcing YubiKey authentication on only certain actions at a time. For instance, you can start with enforcing YubiKey on users requesting role elevation in PIM. Implement this as follows:
    • First, we will set up a conditional access context to attach to a PIM role. In Microsoft Entra, go to Conditional Access | Authentication Contexts.
    • Select + New Authentication Context, and set a Name:
      
      
    • We will now add this context to the relevant PIM role(s). In Microsoft Entra, go to Privileged Identity Management >Manage > Microsoft Entra roles > Manage > Roles. Select the Microsoft Entra role that you want to add YubiKey enforcement to. 
    • Click on Role settings > Edit and under the On activation, require dial, select Microsoft Entra Conditional Access authentication context. From the drop-down, select the authentication context that we created:
    • You can repeat this step for all Microsoft Entra roles that you want to apply YubiKey enforcement for. 
    • For the final step, we need to complete our Enforce YubiKey conditional access policy we started creating. To do so, under Target resources > Select what this policy applies to, choose Authentication context and select the authentication context we created. 

And we’re done! YubiKey has now been enforced for the subset of users/actions that we’ve chosen. Continually repeat Step 5 for wider scopes until we have covered all user groups/ actions, and YubiKey enforcement has been applied organization-wide. If you have guests in your tenant, ensure you don’t accidentally include them too when targeting all users (unless that is your intention).  

Note also that when YubiKey has been enforced organization-wide, you should ensure to exclude your breakglass Microsoft accounts from this conditional access policy (and all others), to prevent it from getting locked out of Entra ID when there are any misconfigurations in conditional access policies. You can (or should) of course still register YubiKeys for breakglass accounts, as dependent on risk assessments carried out in your organization. As these breakglass accounts are being excluded from the Yubikey-enforcement conditional access policy, you should also monitor sign-in events using these accounts to ensure their usage is restricted to calamities.  

Once this Conditional Access policy has been created and applied to all employees and all resources, a user logging into a target application will experience a prompt to authenticate with their YubiKey. An interaction with existing policies that target your session validity may influence how often a user may have to use their YubiKey in a day (see Microsoft’s Known issues documented here). We draw your attention to this as a YubiKey is a physical authentication device, so users may find it handy to keep their YubiKeys inserted in their laptops as long as they are sitting behind their desk. It is then also important to educate them on its removal when they leave their desk. 

New users

Moving onto another stage of the lifecycle, let’s handle the registration of authentication methods for new users. This is a more involved process, and there are a few problems we need to tackle: 

• As stated earlier, the registration of the YubiKey to a Microsoft account cannot be done without registering another form of MFA first.  
• We don’t want to distribute passwords. 
• A user cannot register password-less Microsoft Authenticator App directly from their phone, as they do not yet have a signed-in session to verify their identity. 

How can we solve these problems while ensuring the process we design remains secure? After some thorough threat modelling, the final process we landed on was this: 

Figure 1 - Device onboarding workflow

Given the chicken-and-egg dilemma of how to trust a user who has not yet set up their trusted session, we have decided to leverage an already trusted user and device, who we call the Onboarding Buddy. The Onboarding Buddy can be selected as you deem appropriate in your organization; for smaller organizations, this can be a colleague in the same team as the new employee. For larger organizations, this can be dedicated IT staff. Note that this design entails that you need to physically be next to a trusted device/colleague when onboarding; remote onboarding is thus not supported. 

On onboarding day, the new employee sits with their Onboarding Buddy and authenticates with a Temporary Access Pass (TAP) to their new Microsoft account in an incognito browser session on the Onboarding Buddy’s laptop. Once authenticated, they register their YubiKey and Microsoft Authenticator App. They then enable password-less sign-ins directly on Microsoft Authenticator App on their phone, and finally, they enroll their MacBook into Intune. Behind the scenes, a TAP is being created and distributed and delicately timed conditional access policies are being applied. Let’s implement the behind-the-scenes for the ‘Device onboarding workflow’. 

Behind the scenes: TAP distribution

• First, we need to enable the TAP authentication method. This will be our bootstrapping authentication method, allowing our users to sign-in to their new accounts without a password. To do so, go to Microsoft Entra, launch the Authentication Methods blade, and select Temporary Access Pass. 
• Under the Enable and Target tab, toggle on Enable:
• Under the Configure tab, select Edit and choose the following configuration:
• Our key security considerations are to make the TAP a one-time valid authentication method, set the validity for an hour, and set a sufficiently long length (12 characters). 
• Now that the TAP is an eligible authentication method, it is ready to be created for a new user on onboarding day. We recommend automating this distribution with a scheduled Azure Function App. You can start with polling your HR database for any new employees starting within the following few days, and create a TAP for them through the temporaryAccessPassMethod of the Microsoft Graph API. To prevent misuse of the TAP, set the lifetimeInMinutes property to an hour, and the startDateTime property to the time where you expect the employee to start the onboarding process at the office. Consider the following PowerShell snippet as an example, where we expect the new employee to perform Step 1 of the ‘Device onboarding workflow’ between 10 and 11 CET:  

$objIdEmp = “”  # The object ID of your new employee goes in here 
$uriTap = "https://graph.microsoft.com/v1.0/users/$($objIDEmp)/authentication/temporaryAccessPassMethods" 
$tenOclockToday = $today.Date.AddHours(9)  # 9 UTC (Function App environment) implies 10 CET 
$tenOclockUtc = [System.TimeZoneInfo]::ConvertTime($tenOclockToday, $utcTimeZone)             
 
$uri = https://graph.microsoft.com/v1.0/users/$($objIDEmp)/authentication/temporaryAccessPassMethods 
$body = @{ 
  isUsableOnce        = $true 
  lifetimeInMinutes   = 60  # Valid for 1 hour (window 10-11AM)  
  startDateTime       = $tenOclockUtc 
} 
$tap = (Invoke-GraphRequest -uri $uriTap -method POST -body $body).temporaryAccessPass 
 

• Once the TAP has been created, you need to distribute it to your new employee. Here you can again leverage the trusted Onboarding Buddy. To distribute the code securely, the 12-digit TAP can be split into two parts, where the first half can be emailed to the personal email address of the new employee (as obtained by HR during employee onboarding) and the second half can be emailed to the company email address of the Onboarding Buddy. 

Now that the TAP is ready for the new employee to use, let’s have a look at how to enable its usage. 

Behind the scenes: Enable TAP usage on onboarding day

•  We start by creating a new authentication strength which should include the TAP. In Microsoft Entra, visit the Conditional Access | Authentication Strengths page. 
• Create a + New authentication strength, which we will call Onboarding MFA. Select the following authentication methods:
• Remember to add the AAGUIDs of the YubiKeys allowed by your organization under the Advanced options of Passkeys (FIDO2). 
• Now that we have our onboarding strength, we need to ensure it only applies to new employees who are present in the office. Let’s go to Microsoft Entra | Named locations and register our office IP address. Select + IP ranges location, then add the IP ranges for all traffic from your office location. 
• Next, we create an access package which we can place the new employee into for a limited amount of time.  
  • First, we will create a security group for our access package. In Microsoft Entra ID, go to Groups > New group > and create Security group type where the Membership type is Assigned. We will call this group: H2 New Employee At Office. 
  • In Microsoft Entra, go to Identity Governance | Catalogs and create a + New catalog, which we will call H2 Access Catalog. This will contain all the resources used by access packages in our organization. 
  • Click on the catalog we just created and then go to Resources > Add resources > + Groups and Teams > and select the H2 New Employee at Office security group. This will make our security group available to our catalog. 
  • Then go to Identity Governance | Access packages, and create a + New access package. Under the Basics tab, we will name this access package [H2 AP] New Employee and select the H2 Access Catalog  from the Catalog  dropdown. 
  • Under Resource roles, we will + Groups and Teams and select the H2 New Employee at Office security group. 
  • Under Requests, all pre-filled settings can remain as selected, and we additionally select Yes under Enable new requests:
  • Under Lifecycle, select Access Package assignments expire within 1 day:
  • And save the newly created access package. 
• We now have all the resources that we require for our conditional access policy: an Onboarding MFA authentication strength, named location office IPs, a H2 New Employee at Office security group and a [H2 AP] New Employee access package. Let’s create the policy! In Microsoft Entra, go to Conditional Access | Policies, create a + New policy, which we will call “New Employees”. 
  • Under Users, select Include > Select users and groups > Users and groups and select our H2 New Employee at Office security group. 
  • Under Target resources, select All resources. 
  • Under Network, select Configure as Yes, then Include > Selected networks and locations and select our organization office IP. 
  • Finally, under Grant access, select Require authentication strength to Onboarding MFA and save the policy. 
• You might be wondering now how this policy will be applied, as we created the H2 New Employee at Office security group, but there are currently no members in it. For this, we recommend again to automate this with an Azure Function App. The same Function App we suggested using for the distribution of TAP codes can be extended. To this, we add a subsequent API call that creates a user assignment request for the [H2 AP] New Employee access package from our new employee. Earlier, we suggested the new employee can finish Step 1 (and 2) between 10-11 CET on onboarding day. Given that we assumed the onboarding day starts at 10 CET, we can assign the employee to the access package as follows: 

$objIdEmp = “”  # The object ID of your new employee goes in here 
$APNewEmployeeAtOfficePolicyID = “” # Policy ID assigned to the "[H2 AP] New Employee at Office" access package 
$APNewEmployeeAtOfficeID = “” # Object ID of the "[H2 AP] New Employee at Office" access package 
$uriAssignmentRequest = "https://graph.microsoft.com/v1.0/identityGovernance/entitlementManagement/assignmentRequests"  
$elevenOclockToday = $today.Date.AddHours(8)  # 8 UTC (function app environment) implies 10 CET 
$elevenOclockUtc = [System.TimeZoneInfo]::ConvertTime($elevenOclockToday, $utcTimeZone) 
$body = @{   requestType  = "adminAdd" 
  assignment = @{ 
    targetId            = $objIDEmp 
    assignmentPolicyId  = $APNewEmployeeAtOfficePolicyID 
    accessPackageId     = $APNewEmployeeAtOfficeID 
  } 
  schedule = @{ 
    startDateTime       = $elevenOclockUtc    
  } 
} 
Invoke-GraphRequest -uri $uriAssignmentRequest -method POST -body $body 

• As a final step, let’s implement an inverse of the New Employees conditional access policy to ensure that any employees who are in the H2 New Employee at Office security group but are not at the office, are not allowed to use any non-YubiKey authentication methods. 

  • In Microsoft Entra, go to Conditional Access | Policies, create a + New policy, which we will call “New Employees not at the Office”. 
  • Under Users, select Include > Select users and groups > Users and groups and select our H2 New Employee at Office security group. 
  • Under Target resources, select All resources.  
  • Under Network, select Configure as Yes, then Exclude > Selected networks and locations and select our organization office IP. 
  • Finally, under Grant access, select Require authentication strength to YubiKey and save the policy. 
    

How will this newly created policy impact a new employee performing Step 1 of the ‘Device onboarding workflow’? Armed and enabled to use the TAP, the new employee should now be able to register their YubiKey and Microsoft Authenticator App without trouble. Step 2 is simple in terms of what happens behind-the-scenes, as it requires no special configuration. The user can simply enable password-less sign-ins on their mobile phone without any changes in the conditional access policy. Note that though the behind-the-scenes are simple here, authentication using YubiKey on mobile should still be thoroughly-tested across different mobile OSes and particularly when upgrades occur, lest you stumble into (now resolved) issues such as these... Step 3 also requires no further changes to the conditional access policy; the user can simply use their newly registered YubiKey to authenticate to the Company Portal app when enrolling their new MacBook to Intune. After onboarding day is over, the access package will have expired and the employee will adopt a ‘regular user’ persona, using only their YubiKey for password-less authentication. 

Unavailable YubiKeys

The final lifecycle activity we need to take care of relates to users who block their YubiKey PINs or break, lose, or forget them at home. We designed the registration of the password-less Microsoft Authenticator App as part of user authentication method registration, to ensure that we have a solution for these users. With this secondary form of authentication, we can ensure users who are eligible can continue their work. We want to ensure the window where we allow users to authenticate with other forms of authentication (which are not phishing-resistant), is as narrow as possible. To achieve this, we utilized HR as our entry point for this process. 

An employee who finds themselves in a situation where their YubiKey is unavailable, must contact HR and report the status of their YubiKey. HR performs identity verification and either approves this request or deems it ineligible (i.e. a user who has forgotten their YubiKey at home without good reason has to go back home and retrieve it). If the request is approved, HR initiates a request to IT, which in turn triggers a conditional access policy allowing the user to authenticate with password-less Microsoft Authenticator App. We defined the following restrictions for this: 

• YubiKey lost/broken? The user is allowed to authenticate with password-less Microsoft Authenticator App for 2 days, to give them enough time to pick up and register a new YubiKey. 
• YubiKey pin-blocked/forgotten? The user is allowed to authenticate with password-less Microsoft Authenticator App for 1 day. 

Behind the scenes: Conditional access policies for unavailable YubiKeys

• Let’s start with an access package.  
  • First, we will create a security group for our access package. In Microsoft Entra ID, go to Groups > New group > and create Security group type where the Membership type is Assigned. We will call this group: H2 YubiKey Unavailable Users. 
  • In Microsoft Entra, go to Identity Governance | Catalogs and click on the H2 Access Catalog that we created previously. Go to Resources > Add resources > + Groups and Teams > and select the H2 YubiKey Unavailable Users security group. This will make our security group available to our catalog. 
  • Then go to Identity Governance | Access packages, and create a + New access package. Under the Basics tab, we will name this access package [H2 AP] YubiKey Unavailable and select the H2 Access Catalog  from the Catalog  dropdown. 
  • Under Resource roles, we will + Groups and Teams and select the H2 YubiKey Unavailable security group. 
  • Under Requests, all pre-filled settings can remain selected, and we additionally select Yes under Enable new requests.
  • Under Lifecycle, select Access Package assignments expire within 2 days, and allow the option Users can request specific timeline:
  • And you can save the newly created access package. 
• Next let’s create the conditional access policy. In Microsoft Entra, go to Conditional Access | Policies, create a + New policy, which we will call Employees with unavailable YubiKeys. 
  • Under Users, select Include > Select users and groups > Users and groups and select our H2 YubiKey Unavailable Users security group. 
  • Under Target resources, select All resources. 
  • Under Network, select Configure as Yes, then Include > Selected networks and locations and select our organization office IP. 
  • Finally, under Grant access, select Require authentication strength to Password-less Authentication and save the policy. 
• All that remains is to handle the requests that come in from HR for employees with unavailable YubiKeys. We recommend setting up another Azure Function App for this, where you monitor some database where HR has front-end access to indicate the status of each user’s YubiKey. To handle a lost/broken/pin-blocked YubiKey, you would need to first delete the YubiKey from the user’s authentication methods, which you can do through the fido2AuthenticationMethod API. You can then place an access package assignment request for the user to the [H2 AP] YubiKey Unavailable access package, for the duration of time relevant. 

Recommended security 'extras' 

Now that all lifecycle activities have been implemented, let’s discuss some recommendations on what to additionally configure to ensure we have not opened our security backdoor any wider than we need to. 

• [Monitoring for TAP creation events]: The TAP is a very sensitive form of authentication, acting as a bypass to MFA. To ensure this is not misused, you should monitor your Entra ID audit logs and report on admin/user registration of TAP. 
• [Clear out the [H2 AP] YubiKey Unavailable membership after YubiKey registration events]:  We suggested giving users 2 days to set up new YubiKeys in case they lost/broke their YubiKeys, but they may not need the full 2 days. To ensure they switch back to YubiKey authentication as soon as possible, we can monitor the audit logs for members of the [H2 AP] YubiKey Unavailable access package, and search for any recent FIDO2 registration events. If we encounter these, we assume the user has registered their new YubiKey, and they can be removed from the access package prematurely. This again, can be handled through a scheduled Azure Function app which polls the audit logs. 
• [HR social engineering training]: We rely on HR to handle calls from users who report their YubiKeys as unavailable. To prevent HR from falling victim to social engineering tactics, training should be given by the organization’s security teams. Additionally, you can instruct HR to be even stricter with these requests, by only accepting reports done in-person at the office. However, with this approach, you need to consider how you want to support employees who are working at client locations, or from home.  
• [Session security: Defending against token theft]: A critical yet often overlooked part of enforcing phishing-resistant authentication is session token management. Once a user has authenticated, a session token is issued—if this token is compromised (e.g., via token theft or a vulnerable device), attackers may bypass MFA altogether. To mitigate this, it is essential to configure appropriate session lifetimes via Conditional Access > Session Controls in Entra ID. You can define policies such as sign-in frequency or require re-authentication after a set number of hours or upon risky behavior. Striking the right balance here is key: too short, and users will complain; too long, and you erode the benefits of stronger authentication. In our organization, we tuned these settings to align with device trust (e.g., compliant devices can hold longer sessions) and user roles (admins re-authenticate more frequently). This is your second line of defense after the YubiKey—don’t skip it. 

Conclusion

We’ve now enforced YubiKey for all users, enabled secure self-registration for new hires, and provided clear paths for users whose keys are lost, broken, or PIN-blocked. Primary sign-ins are now passwordless. To avoid weakening controls, we tightly monitored Temporary Access Pass (TAP) issuance and applied Conditional Access with time- and location-based constraints whenever TAP or the passwordless Microsoft Authenticator app was used. 

Before you begin, test registration and sign-in across all operating systems and key app surfaces in your tenant (ideally in a test tenant), and ship thorough user docs with screenshots. 

Pro-tip: Measure success: track FIDO2 registration rates, break-glass account usage, TAP issuance, help-desk ticket volume, and time-to-recover for lost keys. Iterate policies as the org (and Microsoft’s features) evolve. 

On the radar — Microsoft features that may simplify things further as they mature: 

• Admin-assisted YubiKey registration (register on behalf of users, in preview) 
• Software passkeys in Microsoft Authenticator 
• Web sign-in for Windows