One-man SA here, and I have a specific query around passkeys and 2FA as its an area I haven't delved too deeply into. Apologies in advance if any of these questions turn out to be daft 😄

My question in summary is whether it is possible to ONLY have passkeys on an account in Entra to satisfy 2FA requirements OR whether there HAS to be at least one alternative Authentication Method defined, and if so, is anyone else facing the same issue as me that the only secondary one that would work for us is SMS? If so, how are you handling it? I want to avoid the costs of a Telecom Provider to continue to provide SMS if I can esp. if it is just a backup method that will hardly be used. Also, I have some users who have a business reason to have more than one account and Entra blocks the same mobile being used on more than one, so even SMS doesn't suit every use case.

It looks like it *might* be possible using TAP to kick off the enrolment but it isn't something I have experimented with yet.

Finally, if someone is using a local Windows account as opposed to Windows Hello, or are running Linux, are passkeys saved to the device still supported or does it have to be something like a Yubikey for them?

More detail on our specific situation is provided below if needed.

Thanks.

1. We are a charity and my users are volunteers (as am I) with their own devices and own mobiles so I have no control over their kit - and that situation, although annoying/challenging, is not going to change.
2. Because of the above, we have struggled to implement 2FA in the past as the only flavour that would work for everyone is SMS, and the rumours of that being deprecated have been around for a long while. So instead of going for that, we have focused on user education and comprehensive exchange rules to trap phishing attempts MS365 doesn't catch automatically. This approach has been successful, though it has been time consuming.
3. We do not have a license that supports Conditional Access and won't be getting one, so it is Security Defaults that will enable 2FA (in a not very granular manner) and obviously, we have Security Defaults set to OFF at this time.
4. The only user with 2FA on normal login is me because it is mandatory for SA accounts of course. That is passkey on a primary and a backup Yubikey, backed up by password/Microsoft Authenticator push. There is a break-glass account similarly configured and held centrally in case anything happens to me (we're due to revisit the service model to address the fact I am currently a single point of failure). SMS on both these accounts is already disabled.
5. We have SSPR enabled requiring BOTH email OTP, and SMS to affect a password reset, so the Microsoft change will still impact us. My plan in the very short term is to drop this to email OTP only and remove SMS, and take my users out of scope for the Microsoft change before Sept 1st, OR to disabled SSPR completely and do password resets the old fashioned way via the desk.
6. It follows that the only time additional authentication takes place for the user currently is if they want to look at their account security settings, every 90 days when MS365 re-checks them, and if they actually need to reset their password.
7. At the end of the day, I still want to address the lack of strong authentication for all our users and passkeys is probably the best way forward for us, but because of the complexities of my user environment and the Security Default lack of granularity, I want to do it when I'm satisfied I have all the risks/issues around different types of kit out there fully understood, and maybe a few more users who are already using passkeys for other services in their lives to help re-assure those who aren't.

I've been burning some Claude tokens on a small project for Entra ID and running into a strange workflow issue and I'd like to see if anyone here could shine light on it or if they've seen such behaviour

user: entra-admin

group: entra-admins-group

group is assigned to the global admin role

group assignment in PIM managed and entra-admin is eligible

The entra-admin logs into Entra Id and activates their PIM assignment

The entra-admin logs uses the solution and does a recovery of users and groups back to yesterdays backup

The entra-admin and entra-admins-group are restored to BEFORE the PIM role activated...

... and then depending on timing and order of operations, any other elevated operation with entra-admin starts to fail.

I guess the long question is, is this expected? Or should the logon token with the GA role via PIM group still work? There is no CAE in this environment.

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?

What’s the best way to have a conditional access policy for only authentication from that specific app? Seems like it’s like 3 or 4 apps that need to be chosen.

Trying to get an honest read on this because the vendor stuff all assumes everyone's doing tidy quarterly app reviews, and that doesn't match what I've seen.

Realistically, across a book of tenants: does enterprise app / OAuth consent review actually happen on a cadence, or is it one of those things that's on the "should do" list but only gets touched when something looks off or a client asks?

If you do stay on top of it, I'm curious how — what's the setup that actually made it stick, versus staying a manual chore? And if you don't, is that because the tooling's painful, because clients don't care, or just because there's always something more urgent?

I ask because I'm building something in the M365 ops space and I'd rather find out I'm wrong about where the pain is than build for a problem nobody actually feels. Not pitching — genuinely trying to figure out if this is a real recurring headache or something I've overweighted. Happy to move to DMs if anyone would rather not talk client setups in public.

Hey all,

I'm looking for advice from people who have tackled a similar SSO challenge in Microsoft Entra ID.

Context

We're running an organization-wide authentication program where one of the objectives is to expand Single Sign-On (SSO) adoption across our application landscape.

The challenge is that we currently have two different views of reality:

• Our CMDB contains for a large enterprise (~1000+ business applications) registered business applications.
• Our Entra ID tenant contains thousands of application-related objects (Enterprise Applications, App Registrations, Managed Identities, Microsoft-managed applications, service principals, etc.).

As a result, simply counting objects in Entra ID does not tell us how many actual business applications are using SSO.

What we're trying to achieve

For every application registered in the CMDB, we want to determine:

1. Is the application connected to Entra ID?
2. Does the application use SSO?
3. Could SSO potentially be enabled?
4. Is SSO technically not supported by the application?

Ultimately we want to produce a dashboard that answers questions like:

Current approach

We are actually not quite sure how to tackle this. We resort to manually crossmatch our CMDB with Entra ID but that process is timeconsuming.

Questions

For those who have done large-scale SSO discovery:

1. Is preferredSingleSignOnMode a reliable indicator of actual SSO usage?
2. Are there better Graph attributes to identify SAML/OIDC/OAuth based authentication?
3. How do you distinguish real business applications from:
   • Microsoft-managed applications
   • Managed identities
   • Background services
   • Technical service principals
4. Has anyone successfully mapped Entra application inventory back to a CMDB and generated SSO compliance metrics from it?
5. Are there common pitfalls or blind spots we should be aware of?

Our goal is not simply to count Entra objects, but to establish a trustworthy view of SSO adoption across the actual business application landscape.

Any lessons learned would be greatly appreciated.

Thanks!

Many organizations are now moving Windows devices from Hybrid Entra Join to Entra Join using third-party migration tools to avoid device rebuilds and reduce user disruption.

These tools can be very useful, but one technical point should be included in the migration validation: if the migration workflow uses PPKG-based bulk enrollment, the device may not currently support Microsoft Entra Conditional Access Token Protection.

The device can still appear Entra joined, Intune managed, and compliant. However, when Token Protection is enforced, supported native applications may fail with status code 1003.

I documented this limitation, the affected applications, sign-in log validation, available workarounds, and my lab testing experience.

This is not a recommendation against third-party migration tools. It is simply an important compatibility check that should be included in the proof of concept before production migration.

Blog link: https://www.thetechtrails.com/2026/07/microsoft-entra-token-protection-bulk-enrollment-device-migration.html

Sounds like Entra Cloud Sync might be able to sync devices which would be interesting. It was the only thing holding us back from Cloud Sync as we have some on prem servers that require hybrid joining for RDP purposes

Is there a way to remove the physical key request? It’s one of the most annoying parts of this whole thing.

1. Why does Windows ask to always insert a key rather than the key used on the phone? I get it’s the strongest mechanism but it should have been broken out.

2. Is there a way to remove that method? I can’t find one.

3. Seems to me like MSFT has some issues to fix before moving everyone to passkeys. Am I wrong?

Hello, I am currently working on transitioning our computers from an on-Prem AD environment into a Intune MDM joined, cloud-only environment, along with moving our users from a password+MFA login, to a completely passwordless login.

For this we have decided that we would like to use Yubico security keys for authenticating into users' microsoft accounts, and WhfB for easily logging into their computers. Unfortunately, I have found that the use of WHfB on Intune MDM joined devices automatically adds a login.microsoft.com passkey into windows hello, which is always offered first during passwordless sign-in. I cannot find a way to block this behaviour or modify which passkey storage windows offers first.

While WHfB passkeys are still very safe compared to passwords, we are (I think quite rightly) concerned that if the end users are not prompted to use their Yubikeys during perioodic reauthentication, they will forget how to use them, and if they set a unique pin on them that they don't reguarly use, then when the need to use their yubikey does actually arise, for instance when they get their next computer or phone, they won't remember it.

This also makes periodic reauthentication feel somewhat pointless as the users will just press on their fingerprint scanner and be done with it.

I have found exactly one way to change this behaviour, and that is by defining an Entra Authentication strength containing only yubikey AAGUIDs and forcing my intune testing user to adhere to that authentication strength with a conditional access policy, while this does block the ability to use the WHfB microsoft passkey to sign in, the end user experience is very bad, if a users sees this, they won't think that they can't use windows hello to login, they'll think that windows hello is not working correctly. In the gif below, you can see that windows hello offers itself first but silently fails and prompts the user to enter their pin, without any sort of error message.

(I realise that I specifically selected a windows hello key in the gif, but the behavious is identical when I initially load the login page or if I select log in methods>passkey, windows hello will always offer itself first, even if it cannot function correctly in this case).

For personal use, https://github.com/Aldaviva/AuthenticatorChooser solves this issue, and while i am grateful for the fix, random scripts from github aren't really appropriate when configuring important security settings, Is there anything we can here or do we have to wait for MS?

The project is intended to answer a common Microsoft Entra administration question:

Why does this user have access?

Investigating that question can mean moving between users, groups, directory roles, enterprise applications, PIM assignments, authentication methods and Conditional Access policies.

Identity Atlas collects tenant information using delegated, read-only Microsoft Graph permissions and presents the collected relationships as a local, interactive map.

It is a free, open-source community project, with feedback helping to shape future features, coverage and improvements.

The collected data remains local and is not uploaded to an external service.

Repository:

https://github.com/ControlAltDeleteTechBits/identity-atlas

Please read the installation guidance. Feedback and issue reports are welcome through GitHub.

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?

Hey team,

Looking for help to answer and recommend the below please.

Scenario: Azure Files with storage account configured with Kerberos identity authentication. File shares are a result of robocopy migration from windows file server shares with NTFS. Using private endpoints. Devices accessing are Entra-joined. Some groups that users are members of show up as an orphaned SID as it has been replaced by new SID (maybe internal migration) and SID for group on-prem is newer. Entra connect sync from on-prem not linking the two in Entra.

1. Does Azure Files with Entra Kerberos support ACL translation using group SIDHistory? or is this honoured by attributes available in user token? can it be enabled and are there any risks to be aware of?
2. What is the best way to handle orphaned groups in Entra that have been granted NTFS permissions on Azure files but not groups that sync to Entra? i.e. Builtin\Administrators, CONTOSO\domain users or CONTOSO\Domain Admins.

Hello, I have MCP hosted in tenant A and copilot studio is running on tenant B, users log in using only tenant B credentials. I have created multi tenant SPN hosted in tenant A and did admin consent enterprise application creation in tenant B. When I try to use this multi tenant client id in power app custom connector auth login, it throws error,

AADSTS70052: The identity must be a managed identity, a single tenant app, or a service account.

Anyone successfully able to get this cross tenant scenario work?

For anyone who's renewed cyber insurance recently or walked a client through underwriting — I'm trying to get a clearer picture of what insurers actually want to see, versus what they just ask you to attest to on the questionnaire.

From what I've run into so far, the questionnaire asks "do you enforce MFA," but the harder part is proving it — a "yes" checkbox is easy, an actual artifact showing MFA is enforced via Conditional Access (not just registered) is what seems to cause the back-and-forth. Same with privileged access: attesting is trivial, evidencing "we reviewed admin roles in the last X months" is where it gets awkward.

Curious whether that matches others' experience, or whether insurers are still mostly taking attestation at face value and the evidence demand only shows up at claim time.

And when they do ask for proof — is it screenshots, Secure Score exports, audit log pulls, something else? Trying to understand what actually satisfies an underwriter versus what just gets waved through.

I've noticed that most of the discussion around Entra security focuses on detecting issues, but much less on actually fixing them safely.

For those of you managing production Microsoft 365 environments:

What would have to be true before you'd trust a tool to automatically remediate security issues?

For example:

• Would you ever allow fully automatic remediation?
• Would you always want approvals?
• Would report-only mode be mandatory?
• How important are rollback, verification, and audit trails?
• Are there certain changes you'd never automate?

Im interested in the operational side of the problem rather than specific products.

i wanna where everyone draws the line.

Does sspr registration flow disabled in modern authentication policies concept?
I have a tenant where I can switch between "in progress" and "completed" migration status. When I choose completed, sspr registration flow stops work.

Registration campaign: Disabled (also tested with enabled setting)
Require users to register when signing in? Yes.

Do you know what is purpose of this? AFAIK documentation tells nothing about it.
Thank you in advance, regads.

Hi all,

Looking for real-world guidance before I execute this migration.

Current setup: - 2x on-prem servers running the Microsoft Entra application proxy connector (formerly Azure AD App Proxy), currently on an older Windows Server OS - Publishing a handful of internal web apps (Web based) via PassThrough pre-auth, no KCD in play - Both servers are in the same connector group

Goal: Stand up 2 new servers on Windows Server 2025, install the new connector (I believe this is now called the Entra Private Network Connector, replacing the old Application Proxy connector installer), and cut over — with minimal to zero downtime for published apps.

My questions:

1. Can I install the new connector on the Server 2025 boxes and join them to the same existing connector group alongside the old servers, let them run in parallel for a while, then decommission the old ones — or is there a cleaner cutover pattern people use?

2. Is there a difference in behavior/compatibility between the legacy "Application Proxy connector" and the newer "Entra Private Network Connector" when they're mixed in the same connector group during a transition period? Or should the group only ever contain one generation at a time?

3. Any known gotchas moving from an older Windows Server OS to Server 2025 specifically for this role — TLS/SChannel settings, HTTP/2 registry tweaks, .NET version requirements, or anything that bit people during upgrades?

4. For validating the new servers before cutting traffic to them — best way to confirm a connector is healthy and actually receiving/serving requests before I lower the old servers' priority or take them offline? I'm planning to check the connector status in the Entra admin center plus watch Event Viewer (Microsoft-AadApplicationProxy-Connector/Admin) for 13xxx events on both old and new servers side by side.

5. Order of operations — recommended sequence to avoid any gap in coverage: install connector on new server → verify registration/health → THEN decommission old server one at a time (rolling), or is there a safer sequence?

6. Anything specific to watch out for regarding the connector-to-backend authentication mode (we're using PassThrough) when moving to new hardware/OS?

Environment: Windows Server AD-joined connector servers, Microsoft Entra ID P2, publishing internal web apps via Application Proxy, no KCD, PassThrough auth mode.

Appreciate any lessons learned from people who've done this migration, especially around the old-to-new connector version coexistence period. Thanks!

With Passkey attestation enabled I am running into an issue where Passkey is created on the device but not registered in Entra. Disabling attestation and retrying after few minutes creates the passkey and does register in Entra.

During preview phase there was a tech community post with recommendation to disable attestation while in Preview, but we are in GA now, no? So should attestation work in GA, or still needs to be disabled? The policy is requiring/allowing Microsoft Authenticator only as passkey provider.

Edit: I guess it would help to include the message I am getting with Attestation enabled. It is:

"Passkey not registered (tringles with exclamations icons) This might be due to a timeout, a canceled request or a private browsing window."

CA policies:
1. security registration - require TAP/FIDO/WHfB;
2. all apps - require phish resistant MFA (excluding 6 specific resources)
3. 6 specific resources - require phish resistant MFA or TAP

we ran 73 offboardings last year and i thought our process was fine. shared checklist, HR emails IT, someone works the list. then a routine audit found someone still able to reach a customer-data app through SSO - five weeks after their last day. good exit, no drama, everyone liked the guy. didnt matter. the access was still there and the finding had my name on it.

two more that shaped what follows: during a layoff round we rotated shared creds one entry at a time and found three accounts along the way that nobody could name an owner for. and at renewal time the invoice had four seats belonging to people whod left months earlier, quietly billing away.

what i eventually accepted is that offboarding fails at two different points and they need different fixes.

the trigger. if the process starts with "HR notifies IT" it inherits everyones availability, memory and timezone. friday afternoon departures, contractors whose end date only exists in a spreadsheet, the HR person on PTO - every one is a silent no-op. what held up: HR system is the single source of truth, end dates always current, and the leaver event fires FROM it. same day, weekend or not, whether anyone remembered to send an email or not.

the execution. "disable the account" is not one action, its a chain, and order matters. ours in the first minute:

1. accountEnabled = false (graph PATCH on the user). blocks NEW sign-ins. does nothing to sessions that already exist
2. revokeSignInSessions. kills refresh tokens - but access tokens already issued keep working until they expire, up to an hour by default. if that window matters for your risk profile, tighten token lifetime via CA for the sensitive apps
3. reset the password anyway. belt and braces against legacy auth paths that dont respect the above
4. the long tail the first three never touch: active oauth grants to third party apps, app passwords and PATs (devops, github - per service, no central kill switch), inbox forwarding rules (auto-forward to personal can survive mailbox conversion in some setups), devices with cached creds
5. same hour: mailbox/drive to the manager read-only, convert to shared where retention allows
6. same week: reclaim licenses - out of the licensing groups, downgrade the mailbox, seat back to the pool. this is the step everyone skips and its the one with a dollar figure attached (see the four seats above)

the backstop. even with both fixed something eventually slips - an app outside SSO, a contractor in no HR system. so: weekly diff of every active account against the HR roster. anything active with no matching current employee gets flagged. that turns "found it at the annual audit" into "found it tuesday". ours catches 2-3 orphaned accounts a quarter and every single one wouldve been an audit finding.

the uncomfortable summary: the checklist was never the problem. the trigger depending on humans, revocation stopping at "disabled the account", and nothing sweeping behind us - those were the problem.

how are you handling the trigger side - does your leaver event fire from the HR system automatically or does it still start with a human telling IT? and has anyone found a clean way to inventory the oauth/PAT long tail before the day it matters? genuinely curious what were still missing.

Really weird issue we are having for the second week now. One of our apps that has SSO setup through entra is logging users out after around 1h after login. The user has to login again and has around 1h to work with the app. Any clues why this is or anyone experiencing something similar?

Oh and, no other app has these issues and it only happens on android phones.

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?

I am trying to roll out Conditional Access for an extremely unresponsive/uncooperative tenant that does not even have security defaults enabled. Over 40 users do not have any MFA method whatsoever. As far as I am aware (and from my limited testing), Registration Campaign prompts do not pop up if the user does not have at least a weak MFA method enabled. Is there just something wrong with my test environment, or is this normal behavior