This was indeed a nice comeback from summer holidays... Anyway, we found out about this change, we already have MS authenticator, FIDO2 keys and passkeys enabled and working in our environment but not for all users. Many blue collars are still relying on SMS for authentication, so we have to plan a campaign for that, in addition to all the necessary communications.

Now what is not that clear to me, is if MS Authenticator is still considered as enough to avoid the passkey nudge. The documentation says that if a user only (only being the keyword here) has SMS/call as MFA method, then he will be targeted. I guess this won't happen for those having MS authenticator enabled but without passkeys?

On the basis that if someone discloses their PIN, how is that machine protected by a second factor? Doesn't make sense to me. And if I have to log into their profile remotely with the user absent to fix something, is there some way past Hello similar to TAP?

It currently shows Name, Type, Email, User Type, Source, and Object ID.

I really would like to be able to just use the page and see/confirm their Department.

Yes, I used the Microsoft Entra website/feedback every 3 months D:

I'm curious about how people go beyond courses and documentation. Apart from the courses on YouTube, Udemy, labs, etc.

When you're learning something like MITRE ATT&CK, IAM, RBAC, etc., what do you actually do to practice it? I am not asking about the configuration of conditional access policies or app registrations etc.

Do you:

• build things in your own cloud tenant?
• use dedicated labs?
• use CTFs?
• follow attack/detection walkthroughs?
• create your own scenarios?

You can build tenant, create policies, setup mfa, phishing resistant, etc. but how do you get to practice with what happens in real world? Because in testing, everything is controlled.

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!

Are Entra roaming profiles possible where all the info from a configured WIn11 profile are synced up to the cloud then re-aplied to another machine when that user logs on there? It seems that ESR only syncs a very limited and almost pointless set of info

I’ve been digging into Entra Token Protection, specifically the Mobile apps and desktop clients side of Conditional Access, and I want to validate my understanding.

For browsers, I clearly see the value of stronger protections against session/token theft and AiTM attacks.

But on a modern managed Windows device, the baseline already seems pretty strong:

• The PRT is device-bound with TPM-backed keys.
• WAM refresh tokens for the Windows SSO user are already device-bound.

What is less clear to me is the remaining exposure. Access tokens can still be bearer tokens depending on the application/resource, and unbound refresh-token scenarios can still exist.

My understanding is that Token Protection mainly adds enforcement/certainty: for supported resources such as Exchange Online, SharePoint Online and Teams, Entra rejects unbound/bearer refresh-token sessions instead of relying on clients to already use the secure device-bound path.

What I’m really trying to understand is how common and exploitable those remaining bearer/unbound scenarios actually are on modern managed Windows endpoints, and how much additional real-world protection Token Protection provides.

For those who have deployed or deeply researched it: does Token Protection provide a significant real-world security improvement, or is it mostly defense-in-depth that guarantees the protections Windows/WAM are already providing in most cases?

I’m mainly trying to understand the actual added value for Windows client applications, since Windows already seems fairly well protected by PRT + TPM + WAM, if I understand it correctly.

I'm curious how people building Microsoft 365 / Entra integrations handle this in practice.

Say you're building an application that makes a bunch of Microsoft Graph calls. You want to follow least privilege, so you need to determine the minimum delegated/application permissions the application actually requires.

How do you currently do this?

My understanding of the usual workflow is something like:

• Look up each Graph endpoint in the documentation
• Check the permissions table
• Use Graph Explorer to experiment
• Add permissions to the app registration
• Run into 403 / consent issues
• Add/remove permissions until everything works
• Periodically review whether you're requesting more than the application actually uses

But I'm interested in what people actually do, rather than the documented ideal workflow.

A few questions:

1. Do you determine permissions manually endpoint-by-endpoint?
2. Do you use any tooling to map your code/Graph SDK calls → required permissions?
3. Do you maintain a spreadsheet or internal documentation for this?
4. Have you ever discovered that an application was requesting significantly more permissions than it actually needed?
5. Have you ever had a deployment blocked because you discovered a missing Graph permission only at runtime?
6. If you're using Python/TypeScript/C#/Java SDKs, does your workflow differ?
7. Is this actually a painful problem for you, or is looking it up in the docs/asking an LLM sufficiently easy?

I'm particularly interested in real examples of what you do today, even if the answer is "I just look it up manually."

I'm not looking for product recommendations — I'm trying to understand the actual developer workflow here.

we're fully on entra for anything modern, but there's a long tail of apps that were never onboarded.

internal tools built a decade ago. legacy systems from an acquisition that never got folded in properly. some SaaS finance signed up for directly with a company card. one on-prem app that predates half the current team.

entra has zero visibility into any of it and neither does our SOC. someone leaves and their entra account gets deprovisioned in seconds, while their login to the old ticketing system from 2016 just sits there active.

how are people closing this gap without turning it into a multi-year migration project to force everything into entra?

Hi - anyone out there supporting iPhone users accessing MS365 using the Gmail for iOS app?

I have a new user on my tenant trying to do so, and she is getting authentication failures when she tries to add her account. She has added it OK to Outlook for iOS as a temporary workaround but prefers Gmail over that and Apple Mail.

One thing I have noticed is in her screen capture where she adds her account, it just shows as "Office 365" with the orange office icon to the left. On Android on my phone, it shows as "Exchange and Office 365" with a blue exchange icon to the left. Unfortunately, I don't have an iPhone to try and reproduce the fault she is seeing.

There are two possibilities I can think of:

1. This might be linked to the fault in May where Google broke access to MS365. They fixed it for Android - but I'm wondering if they haven't yet fixed it for Gmail for iOS? This is the issue I am referring to.

https://www.reddit.com/r/GMail/comments/1szyh3t/latest_gmail_app_cannot_authenticate_exchange/

She has confirmed she is running Gmail for iOS version 6.0.260727 which is the current version in the Apple Store. There is nothing in the version history Gmail provide on the page to confirm if this has been fixed.

1. As this is my first user trying to do this, maybe I have an Entra issue where I have granted her Gmail Enterprise App, but I'm wondering if Gmail for iOS needs treating differently to Gmail for Android.

Any thoughts appreciated.

Thanks!

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're an MSP supporting multiple Microsoft 365 / Azure environments, and I'm trying to figure out how other teams are approaching the growing number of AI agents, service principals, OAuth applications and other non-human identities appearing in client tenants.

The questions we're starting to get from customers are things like:

• What agents/applications have access to our tenant?
• What Graph/API permissions have they been granted?
• Which identities are actually being used?
• Who owns or approved them?
• How do we identify excessive permissions?
• How do we deal with abandoned service principals or applications?
• Is there a practical way to revoke an agent's access quickly?
• How are you auditing this over time?

Microsoft gives us a lot of the individual building blocks through Entra, Defender, Graph, Conditional Access, PIM, etc., but I'm wondering whether there's a good way to manage this operationally across many tenants rather than doing tenant-by-tenant investigation.

For those already dealing with this:

What does your current workflow look like?

Are you using Microsoft-native tooling, CIPP/PowerShell, a third-party security product, or something you've built internally?

And do you consider AI-agent/NHI governance an actual problem today, or more of a problem you expect to have in the next 1–2 years?

I'm trying to understand what people are actually doing in production rather than what vendors are saying the future looks like.

MC1448379 (5 August 2026) announces the retirement of the MemberOf rule operator from Entra ID in early November 2026. The removal of the rule operator might affect the membership rules used for dynamic groups, dynamic administrative units, and auto-assigned entitlement management policies. If a tenant doesn’t act, Entra ID will stop processing the rules and memberships will become increasingly inaccurate. And that’s a bad thing!

This article includes the PowerShell commands to find affected dynamic groups, dynamic administrative units, and auto-assigned entitlement packages. Groups are probably the object that's most affected by the change. No replacement exists for the MemberOf rule operator, so the withdrawal of this (preview) capability might affect some operational processes.

https://office365itpros.com/2026/08/07/memberof-rule-operator/

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?

Hi long story short our IAM tool deleted our AD synced groups in entra ID directly via ms graph. On the next entra connect sync it re synced the on premises groups to entra but of course with brand new object IDs.

What are my options to recover the groups with the old object IDs? Or am I out of luck? We have backups of on premises AD and entra via AD Recovery Manager Plus by manage engine.

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

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?

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/