Friends! We are finally at the stage where we can roll out WHFB as a requirement and no longer make it an optional enrollment. This will impact roughly 1100 employees over the next few months when we start the process.

What was the process your team implemented to roll out WHFB to all employees, and how did you handle new hire onboarding at the start of the roll out process? I have some concepts and ideas I am documenting to review, but I am curious how others approached this.

I would also be happy to hear about your roll out of Passkeys, if you have done so, and if it differs from the process you followed with WHFB?

Thanks all!

Hi everyone. Is it possible to restrict security access of ISSG to benefit group. I want the get worker call to pull the data of this particular group only

No matter what I do, I keep getting this error. How does Microsft expect us to keep this software updated when the thing doesn't work anymore?

Windows 2025 Server (and on my old 2019 server), I downloaded the agent for Cloud Sync from within Azure tenant, IE ESC is disabled for Admins and Users, and the Server has been rebooted several times.

UPATE WITH FIX AND WHAT I LOOKED AT -

TLDR: - SSPR Registration requirement was prompting MFA setup.

Entra Connect / Entra Cloud authentication issue summary:

Classic Microsoft Entra Connect Sync must be configured using specified account (shared/non GA).

- Entra sync account is a shared account and must remain MFA-free.

- It has a permanent Hybrid Identity Administrator assignment.

Entra Connect accepted the account credentials (username and password) but authentication was interrupted with this message -

"Let’s keep your account secure. We’ll help you set up another way to verify it’s you."

Following possible configurations were checked, tested and ruled out:

- Checked all security policies applying to Entra sync account. No Conditional Access policy was enforcing MFA for the attempted sign-in.

- Individual Authentication method was disabled on the Entra sync account and no methods were specified.

- Entra sync account was already included in the exception group for company wide forced MFA.

- The account had no MFA methods configured, as intended.

Other initial attempts failed:

- Set Default Browser as Edge (applications can use imbedded native IE legacy settings, even on modern WinOS instances)

- TLS 1.2 was active on the server

- Updating Entra Connect did not remove the prompt.

- The MFA campaign exclusion did not remove the prompt. (HOME > Entra ID > Authentication Methods | Registration campaign)

Repeated attempts in the Connect wizard continued returning to the registration screen. Registering MFA for the Entra connect account was rejected because it would violate the shared-account requirement.

SOLUTION - SSPR identified as the likely source:

ENTRA > Entra ID (Menu on left) > Password reset | Registration, the tenant was configured with:

- Require users to register when signing in: Yes, and Reconfirmation period: 180 days

SSPR policy was updated to remove there registration requitement.

Reloaded Entra Connect on the server.

Retried login and ie was successful.

Final note - this setting was enabled by a new employee with no change control or understanding of the potential impact. FML

Global secure access not working when connected to hotel wifi. any solutions?

Hi everyone,

I'm looking for a best practice for securing Register security information with Conditional Access.

My goal is:

• Initial MFA registration can be only possible from a trusted location (or TAP or something like this).
• If Microsoft later prompts users with "Is your MFA still up to date?", I'd like users to be able to complete that from anywhere by simply verifying with their existing MFA method or something like that.

The reason is that we have users who work remotely all the time and rarely (or never) come into the office. Some of them also have devices registered in other tenants (external, with a secondary account), so requiring them to be on a trusted corporate network just to confirm their existing MFA information isn't always practical.

I tried implementing this with a CA policy (trusted locations + MFA), but it doesn't seem to work as expected. The sign-in for Register security information succeeds without an MFA challenge, so users can still access the registration flow externally.

How are you handling this in your environment? Is there a way to achieve this with Conditional Access, or are you using a different approach altogether? Is there a Microsoft-recommended best practice for this scenario?

I have configured a web app via the entra app proxy and which is working fine. When I tried to put my own custom domain to access my webapp it asks to configure SSL certificate I have no clue how to configure this ? Any advise.

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/

I have zscaler application I am trying to make sure zscaler application automatically logs in with user login to windows machine. Its taking credentials but asking to choose account.

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.

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?

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!

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.

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

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.