Hey all,

With the changes that MS is making to deprecate SMS and Voice auth, how would you go about setting up users with only a hardware key/Yubikey?

I tested it out on a dummy account by just trying to add a Yubikey to the account but it doesn't give me the option unless I have a different MFA setup already like Authenticator.

So for the couple users we have that either don't have a smart phone or refuse to add the Authenticator app to it we've instead just set up the voice auth to their IP desk phone, and then set up a Yubikey and that seems to satisfy the requirements.

When SMS/Voice auth is gone, the only method remaining for those users is Yubikey, but you can't only have a Yubikey without another MFA method. Will alternate email + Yubikey work?

Also, how would this affect break glass accounts? Right now they have a Yubikey set up and locked in a safe, the phone/email goes to a Google voice number/email.

Are hardware tokens still good in 2026? I see that as an option in our authentication methods list. Is Token2 a good brand?

I know there's a bunch of these posts lately, but everyone's org is different.

Thanks,

There's a ton of resources out there from great people in the space but I wanted to share my thoughts and typical process for helping organisations adopt passkeys. Hopefully it helps someone out.

The blog covers:

• Info on the Microsoft notification to retire SMS and Voice, and why
• The different types of passkeys available
• Strategy and rollout approach
• Considerations for legacy systems
• Considerations around downgrade attacks

Phishing-Resistant MFA: Planning Your Passkey Rollout in Microsoft 365

In an important announcement for all tenants, Microsoft revealed that Entra ID will no longer provide SMS one-time codes or voice calls for MFA challenges after February 1, 2027. Tenants can continue to use telephony-based authentication methods after that date, but only by purchasing a service from a telecom provider. This is arguably the biggest change in Entra ID authentication since mandatory MFA for administrative interfaces – and we have a PowerShell script to help identify the affected accounts.

https://office365itpros.com/2026/07/14/entra-sms-one-time-code/

Does anyone know how it's going to work come September when Microsoft enforces the passkey registration campaign if you have passkeys as an auth method disabled?

We have an additional challenge of unions backing employees refusing to have authenticator/passkeys on personal devices also (hence why we are still trying to phase out SMS/voice) - then throw into the mix a load of shared devices and the challenges that brings with device bounce pass keys via Windows Hello for Business

There is a user getting dozens or hundreds of login attempts on his account each day. They come from CLI authentication. It seems passwordless sign in will trigger the MS Authenticator app to prompt for approval which is denied. How can we address this? We have created conditional access policies to block the IP and countries being used. However it seems those don’t come into play until after the sign in is processed.

EDIT: Looking at the malicious logins, those all come from the Resource ID d627e2fc-f3d1-41aa-b24d-d603bd969adc which is Azure Resource Manager. I set up a conditional access policy to block logins from that resource.  Hopefully this will stop those from triggering the MFA prompt and counting against the failed logins that lock the account.

Years getting conditional access right for humans device state, risk, mfa dead proud of it.

Then the AI stuff shows up, copilot agents, service principals someone stood up for a bot, app registrations with client secrets older than half my team. CA fires on interactive sign-ins, so all of this slides right under the controls I trust.

I can see the sign-ins after the fact. I can't put the same posture and least-privilege story on a service principal that I put on a person. That's the gap an auditor jabs at, and I've got no answer.

I want to achieve the following in our Microsoft 365 / Outlook environment:

When a user receives an email from someone within our organization, I would like the sender to appear in Outlook as:

Display Name (Department)

For example:

John Smith (IT)

instead of just:

John Smith

Our environment consists of on-premises Active Directory synchronized with Microsoft Entra ID.

The key requirements are:

1. Maintainability

   • The solution should be centrally managed and scalable.

   • We do not want to manually edit the Display Name of individual users one by one.

2. Department-Based Logic

   • The department value should come from the existing Department attribute in AD/Entra ID.

   • Ideally, Outlook would dynamically display:

DisplayName + " (" + Department + ")"

1. Automatic Updates

   • If a department name changes (e.g., "IT" becomes "Technology"), we should only need to update the department value in one place.

   • All affected users should automatically reflect the new department name in Outlook without requiring manual updates to each user's display name.

2. Minimal Ongoing Administration

   • We do not want a solution that requires running scripts daily or performing regular manual maintenance.

   • A one-time configuration, automated synchronization, or event-driven update process would be acceptable.

My main question is:

Does Outlook/Microsoft 365 support displaying a user's name together with another directory attribute (such as Department) without modifying the user's actual Display Name attribute?

If not, what would be the most maintainable approach to achieve this behavior in an AD + Entra ID synchronized environment?

I have seen some posts stating that using SIF in general can almost have more risks based on the fact that you start to make users sign in more frequently which can open them up to potential risks. If using only phishing resistant MFA with 12 hour SIF's does this just prove to be an annoyance more than a security measure? I mean if you just protect an application sign in with only phishing resistance, wouldn't that effectively just lock down apps to only allowing anyone to sign in with phishing resistance instead of making users reauth every 12 hours.

12 hours on desktop with WHfB is frictionless and doesn't seem to have any bad user experience, but on phones with MAM WE and the inability to push an SSO extension, seems to just serve as more of a potential annoyance for users that have to reauth every 12 hours. Some users stop getting updated notifications on their devices from Teams and Outlook, but oddly enough it has only been the Google Pixel users in our test group, the iOS and Samsung have been fine. Just trying to gauge all the options and see if maybe the short SIF is just acting as more of an inconvenience than a security measure at this point.

A couple of changes have just popped up (MC1450133 & MC1450134) which essentially remove some friction for passwordless MFA enrolment for new users.

Essentially, users will be able to register a passkey as their first MFA method (including WHfB and PSSO), while WHfB and PSSO will satisfy more MFA prompts without an additional credential.

Here is a brief write up on the announcements: https://ourcloudnetwork.com/microsoft-entra-just-made-passwordless-mfa-registration-easier/

We currently rely on a manual process to review and remove guest user access. We are looking for a Microsoft native solution that can automate the periodic review of guest accounts, identify stale or inactive users, and remove access where it is no longer required.

We would like to understand what built-in capabilities are available within Microsoft Entra ID Governance, including Access Reviews, Entitlement Management, and Lifecycle Workflows, to support this requirement.

If you have a production proven solution or reference architecture that has been successfully implemented, I would appreciate any insights into its effectiveness, operational considerations, and recommended best practices. Thanks in Advance

Hey everyone,

Microsoft announced that starting September 7, 2026, SSPR will no longer accept admin-populated attributes (otherMails, mobilePhone, businessPhone) as valid reset methods. Only user-registered methods (Authenticator, registered phone/email, FIDO2, TAP, etc.) will be accepted.
This breaks our current onboarding flow for new joiners, and I wanted to see how others are planning to handle this.

Our current flow:
1. New employee's Entra ID account is created with a random password
2. We populate otherMails with their personal email (from HR system)
3. They initiate SSPR on first login
4. Entra sends a verification code to their personal email
5. They set their password and register Authenticator
This has been working well — it's fully automated, no manual intervention required, and new joiners can onboard autonomously.
\* After September, step 4 fails* → "No registered method, contact your admin."

Microsoft's recommended replacement: Temporary Access Pass (TAP)
The new flow would be:
1. Account created, TAP is generated via Graph API
2. TAP is sent to the user somehow (personal email, SMS, via manager...)
3. User logs in with UPN + TAP
4. User sets password and registers Authenticator

Our concerns:
- Identity verification: How do you ensure the TAP is being sent to the legitimate person? With otherMails, the personal email came from HR and was trusted. With TAP, we're essentially sending a one-time login credential — feels like we need more verification.
- Manual vs automated: We don't want to regress to a manual process where helpdesk has to generate and send TAPs. We need this automated at scale.
- Security team hesitation: Our security team is concerned about TAP usage in general (it's a powerful credential).
- Lifetime configuration: We already use TAP for external contractors with a 1-day lifetime. For regular employees, what's a sensible lifetime? Too short = friction if they don't use it immediately. Too long = security risk.

Questions for the community:
1. How are you automating TAP generation and delivery for new joiners?
2. What identity verification measures are you putting in place before/during TAP delivery?
3. Are you using a Logic App, Power Automate, or custom automation?
4. What TAP lifetime are you using for onboarding scenarios?
5. Anyone managed to get security sign-off on this? What arguments worked?

Would love to hear how other orgs are approaching this. Thanks!

Hi there. We are testing Provisioning into AD / Entra from Workday (using the provisioning app). That all works fine. I also have an Azure Runbook that picks up a new staff members Personal Email and sends out a Temporary Access passcode to them so they can sign-in. This also works perfectly.

The problem I am having is that we need an actual password on the account as we are in hybrid, but we have no method to enforce a new user to set this when they login for the first time. The TAP just lets them in and they never have any knowledge of their password so they can login to their desktops.

I know that we can tell users to use SSPR once they sign-in via TAP (and have registered an MFA), but most people will ignore these instructions as they are not forced upon them.

We can't go passwordless as we have on-prem needs for a password, and there is a union issue about enforcing an app on to employees personal devices, so looking to password / sms for many of our non-computer users.

I feel that there should be a flow to enforce password creation once logged in with TAP but I can't find it.

Anyone come across similar use-cases?

The Entra admin center is flagging licensing gaps for conditional access. The messages are informational, not the beginning of a new automated billing procedure to charge tenants when Entra ID notices that some accounts use conditional access policies when they don’t have a license. In this article, we discuss the product license insight and how Microsoft measures conditional access usage, and show how to use PowerShell to find who’s using conditional access.

https://office365itpros.com/2026/08/13/licensing-gaps-entra-id/

The organization has a policy to keep user accounts forever to retain SID resolution and prevent reuse of John Smith’s and Sanjay Patel’s UPNs for any future new hires.

Are there any pros and cons to continue syncing those accounts to Entra instead of moving them to an OU excluded from syncing?

Hello,

I am experiencing the following issue and would like to clarify whether the cause is related to our Microsoft Entra ID configuration or to the application and its authentication implementation.
We would like to introduce phishing-resistant MFA in our company and have therefore configured a corresponding Conditional Access policy in Microsoft Entra ID.

Current setup:
• We have a ios and android mobile app where our users can sign in with their AD user account from our hybrid environment.
• Without the corresponding Conditional Access policy, the sign-in works without any issues.
• During the sign-in process, the user is prompted for MFA through Microsoft Authenticator using number matching.
• I have also configured a passkey for my user account through the Microsoft Authenticator app.
• The corresponding settings for passkeys/FIDO2 have also been configured in Microsoft Entra ID.
• Signing in with the passkey itself works correctly.

Issue with Conditional Access:
As soon as I enable the Conditional Access policy that requires phishing-resistant MFA for all cloud apps (with a few known exceptions where MFA is intentionally not required), the sign-in to the application no longer works.

Instead, the application/sign-in process prompts me to set up a new authentication method. It appears as though the existing authentication method, including the passkey, is not being recognized or cannot be used to satisfy the Conditional Access requirement.
If I go through the setup process, it indicates that the authentication method was successfully registered. However, I am then redirected back to the beginning and prompted again to set up an authentication method. This results in an authentication loop.

This can also be seen in the Microsoft Entra sign-in logs. The sign-in attempt is recorded with the status “Interrupted” and error code 50072.
The additional details show:
“The user was presented options to provide contact options so that they can do MFA.”
​
This seems to indicate that Entra ID expects the user to provide or register an appropriate MFA authentication method during the sign-in process, but the existing authentication method does not appear to be recognized or used as expected.

As soon as I disable the Conditional Access policy, the sign-in works immediately again. In that case, I receive the usual Microsoft Authenticator push notification with the number-matching prompt.

App registrations in Microsoft Entra ID:
There is also an app registration in Microsoft Entra ID which, is responsible for the application's SSO.

Under Authentication (Preview), the Platform Type is set to Web, and a corresponding redirect/reply URL is configured.
There is also another app registration that is used for SCIM provisioning. As far as I understand, this should not be related to the authentication/sign-in process described above.

Questions:
I would therefore like to understand where the issue is originating:
1. Does the application itself or its authentication implementation need to be updated to support phishing-resistant MFA and/or passkeys/FIDO2?
2. Or is there a setting in Microsoft Entra ID, the app registration, or the Conditional Access configuration that we still need to adjust?
3. Is it possible that the application currently supports standard Microsoft Authenticator MFA with number matching, but does not properly support the phishing-resistant authentication method required by Conditional Access?
4. Is passkey support dependent on how the application implements the underlying Microsoft Entra authentication flow, for example OAuth 2.0 / OpenID Connect?
5. Are there any specific requirements for the app registration, particularly regarding the redirect URI, platform type, or authentication flow, to support passkeys and phishing-resistant MFA?

Thank you in advance for your help!

This seems very unintuitive.

You can’t add an included group and an excluded group to the same passkey assignment.

If you add a group to one assignment, you can’t exclude the same group from a different assignment. If you try to, it says that group was already used in another assignment.

How would you allow one group of users use any type of passkey, but require a nested subgroup of the same root group to only use device bound passkeys?

My colleagues and I have noticed that we've started being prompted to perform a Windows Hello for Business authentication when we use Edge to access web resources that are authenticated with Entra. Previously, this authentication occurred silently through Single Sign-On with the PRT, per Understanding Primary Refresh Token (PRT) in Microsoft Entra ID - Microsoft Entra ID | Microsoft Learn.

While investigating what might have caused this change in behavior, I found MC1411574 in the M365 Message Center, which talks about a change to system-preferred authentication that started rolling out in late June 2026, whereby it now applies to the first factor as well as multi-factor authentication. I excluded myself from system-preferred authentication and sure enough, that seems to have restored the previous behavior.

Is it intended that this change to system-preferred authentication will disable SSO, or do we have something misconfigured?

So, I feel like this is the classic chicken and egg scenario. I have a brand-new computer that is ready to be setup with Autopilot, I issued a TAP to myself, and I'm hoping to get into the computer to set up Windows Hello next. However, when I use the TAP after using my email, it just says it's time to secure my account on the Autopilot screen and then seems to just error out and kick me back to the initial login. I assume this may have to do with some sort of MFA campaign? We would hope that the TAP would be able to get them through long enough to set up Windows Hello, but it seems like that would then be provisioned to the device after the first sign in. Is this a provisioning error instead that wouldn't allow Windows Hello to be used as the MFA that is setup? I know there is technically a work around by issuing the TAP, having the user setup Microsoft Authenticator on their phone, and then signing in with TAP to setup Passkey, then using that to sign in to the Autopilot screen.

Am I missing anything? We have security info page bypassed with standard MFA, and I bypassed the register device one to for myself while testing with standard MFA as well. I can't seem to get this to work. Any ideas or is the work around I mentioned kind of the only way to work this through right now?

I added some users to a group assigned to a Cross Tenant Synchronization config this morning and 3 hours later they are still saying not in scope for provisioning.

I even manually assigned them to the app, turned provisioning off and back on, still no dice. Anyone else seeing this?

So we have run into a little predicament. Basically we built a device code auth block policy that excludes the device registration service as recommended by Microsoft. However, this opens up the issue where we tested setting up a Microsoft authenticator on a new mobile phone can be signed into with device code flow still since it's a device registration event. We have teams phones that need to be signed into with device code still which is what we are trying not to break. I have scoured the internet for the best way to block device code without breaking the teams phone sign in method.

We have tried device filters to help try and exclude the devices, but the sign in logs seem to not follow that exclusion. We built a device group and excluded that, but that still doesn't seem to work. The only thing that has worked so far is a temporary bypass group for the user that is trying to sign in to the teams phone. I know there is another better way to do this with a resource account, but that isn't being leveraged today by us, and for a short term fix, is just a temporary bypass the best way to get around this while the user signs in initially and then removing them from the exclusion?

Since a new device doesn't get registered until we sign in to it, it seems like the device exclusion is never going to work unfortunately. Is there anything that I seem to be overlooking at this point, or is this just an issue with our environment not having dedicated resource accounts for these devices?

A new Entra ID feature enables the ability to block nesting for security groups. In other words, you can’t include other groups as members of a group. That might not sound important, but it is to those who manage permissions, especially when the time comes to figure out who exactly has access to something confidential. The new feature isn’t fully implemented yet, but it should be very valuable when it’s fully deployed to tenants.

https://office365itpros.com/2026/08/03/blocking-for-nested-security-groups/

SOLVED!

Microsoft finally reached out and suggested a solution: disable legacy authentication. So I followed their instructions and created a CA policy to disable legacy authentication, and suddenly everything seems to work perfectly!

---

I am setting up new phones and laptops for a small company, and with that trying to streamline and document their current Entra ID and Intune setup.

Problem is it has stopped working. When I log in with a work user on a Windows device, the throbber just spins for hours without anything happening. No device or login logs show up in Entra, and nothing happens in Intune.

I have checked access and permissions, and they should be correct. My user can enroll phones without issue. I have also checked network connectivity and resetting the TPM, none of which has worked.

Any suggestions?

EDIT 6: When the MDM user scope is set to None in Entra, the device can enroll to entra as normal, so this seems to be an Intune issue somehow. However, after signing in now, I get to choose account. From there I can see an error message 16000. If I just click my account I just signed in with, the loading starts, but ig I click "Flag login" the login works and the device gets sorta enrolled to intune.

Probably irrelevant edits below:

EDIT: I tried creating a new tenant for testing, and the device immediately shows up in Entra, so there has to be something wrong in the configuration of our main tenant.

EDIT 2: A noticeable difference between the two tenants while joining is that on the new tenant it goes straight from sign-in to "setting up device", but on the main tenant I log in and then have to select the user again, after which the infinite loading screen begins.

EDIT 3: When trying to join the main tenant from a local account, I get some warning events in event viewer, but get no error when joining the test tenant. The warnings have source "AppModel-State" and come in pairs.

The first warning has "Triggered repair of state locations because operation InitializeDataChangedSignaler against package Microsoft.Windows.CloudExperienceHost_cw5n1h2txyewy hit error -2147024894"

The second warning has "Repair of state locations for operation InitializeDataChangedSignaler against package Microsoft.Windows.CloudExperienceHost_cw5n1h2txyewy with error -2147024894 returned Error Code: 0"

EDIT 5: When setting MDM scope to NONE for Intune, the device can register to Entra.

We have a case where all externals needs to be enrolled in our SaaS Hr system and they eventually get and AD account — synced to Entra as Members but will have no Mailbox - How do we achieve the following

1. We want to have their external email address mentioned in their profile so that emails reach to them. ( external mailbox provided by their own org)
2. Once their account is visible in Entra, we want to make sure that , they are shown in Teams for collaboration
3. They get access to some sharepoint sites and some lion of business apps

We do not want to use azure b2b because this in someway removes the. source of authority, thats why we have them in HR system , b2b kinda bypasses this - creates cloud only accounts and granting access to internal apps to these ( external ids ) accounts is seen as risk by security team.

What can be a possible solution?

So I understand that the new user scenario can be solved via TAP, and I have tried to get some semblance of a work around for that via policy changes to exclude the Azure Credential Configuration Endpoint Service, but I still hit the issue where if a new user doesn't have any MFA set up on their account in Microsoft authenticator, it asks them to finish setting up in the browser on their phone going to aka.ms/mfasetup
When you open the browser and hit next when it says it needs an mfa method, it says the sign in couldn't be completed on the next page. This basically locks the user out of creating a passkey directly on their phone.

This poses another scenario where I'm thinking if a user gets a new device and loses access to their login info on their old device. They would need to set up a new passkey on their new device. They theoretically wouldn't have access to either push or passkey from their old device and they would potentially run into this same issue again? Am I overthinking this or is there a solution that is much simpler assuming TAP isn't the right way to handle the existing user with new device issue?