I am pushing to get all devices entra joined and WHfB enrolled asap, but want to confirm that what I’m thinking is sound: Microsoft is only pushing passkeys for users whose ONLY MFA option is voice/sms, but otherwise authenticator push is still a valid MFA method and using it as our only MFA method will not trigger users to be prompted to setup passkeys. Does this sound correct?
I understand authenticator push is not phishing resistant, and will keep pushing toward a fully entra joined fleet with WHfB, and eventually passkeys to fill in the gap of non-corporate device sign ins.
Remote users are reporting intermittent internet connectivity through GSA, and policy updates for GSA through the Entra portal are not applying after several hours. Disabling GSA resolves the issue with connectivity.
Is anyone else experiencing this? The admin portal currently shows no reported outages.
Managing application sprawl and tracking access in Entra ID deployments can be difficult. I built a tool for my own IAM projects that reports on applications, permissions, certificates, and expiration dates. I am sharing it here to gather feedback.
The tool deploys on-premises and uses a local database, ensuring tenant and security data remains private.
There is a free 7-day trial available to test it out (no credit card required). I welcome technical feedback to help expand the toolset.
I'm enforcing Phishing-Resistant MFA through Entra Conditional Access for our privileged accounts.
Our users have Windows Hello for Business on their Windows 11 workstations and FIDO2 passkeys in Microsoft Authenticator.
Everything works fine locally, but we're running into issues when users RDP into Windows Server 2019 and try to access Azure Portal through Edge or run "az login".
The server doesn't seem to support redirecting passkey authentication to the user's local Windows Hello or Microsoft Authenticator on their phone.
Currently, I'm excluding certain cloud resources from our Conditional Access policies, but I'd prefer to avoid these exceptions.
Has anyone successfully configured WebAuthn/passkey redirection on Windows Server 2019 over RDP, or is this a limitation that requires Server 2022/2025?
I'm currently getting myself up to speed with regards to the SMS/voice retirement and auto-migration to passkeys. I think I've now got a good understanding of the basics, but I still have some questions that I can't find clear answers to - particularly around the auto-migration to passkeys aspect. Some are quite specific, so maybe one for the Microsoft PMs that I know lurk in this subreddit can chip in!
As far as I understand it, part of the auto-migration is a "system-managed" passkey profile that:
Is not visible or modifiable by admins.
Overrides (or at least applies in addition to) any passkey profiles you have defined.
Applies to any user that is enabled for either the SMS or voice auth methods (regardless of whether they actually have those methods registered or use them).
Allows registration of any type of passkey (device-bound or syncable) with no AAGUID restrictions.
This system-managed profile works in conjunction with the registration campaign (which gets auto-enabled in many cases) to nudge users to register a passkey during qualifying interactive sign-ins.
The above changes are starting to roll out on 1st Sept, but the exact date each tenant gets them will vary. For simplicity, I'm going to call these the "phase 1" changes.
Am I correct with all of the above?
Is the system-managed profile always created, or only if the tenant had either the SMS or voice auth methods enabled at the time the checks for the phase 1 changes occurred on that tenant?
What happens if your tenant had both the SMS and voice auth methods disabled when Microsoft did its "pass" for the phase 1 changes, but you subsequently enable them later on? Will the system-managed passkey profile then apply, or is that a one-time decision taken when the phase 1 changes were rolled out to the tenant? I think it's probably a one-time thing, but would be good to confirm. Not an issue as you'd obviously just create your own passkey profile for it - it's just for my knowledge.
What's the easiest way to tell:
If a tenant has been "processed" with regards to the phase 1 changes (regardless of whether any changes were actually made)?
If it has been processed, whether the system-managed passkey profile was enabled?
When I inspect the Graph API traffic using DevTools while opening the Authentication Methods blade in the Entra admin center, I noticed the following features value in the response:
Some tenants have it set toenableDynamicPasskeyPolicyMigration and some to none. Is this telling me whether or not the system-managed passkey profile has been activated in the tenant? In the tenants I've checked so far, those that had either SMS or voiced turned on had features set to enableDynamicPasskeyPolicyMigration and those that didn't had it set to none. This makes me think this value is saying what I think it is, and MS are calling this process "passkey dynamic migration" internally. Is there a better / less hacky way to get the same information? Initially, I thought the below banner would be it, but it seems to appear regardless of the value of the features value in the auth methods policy.
If it appears regardless of the state of the system-managed passkey profile, what exactly is this banner telling me? What is the specific logic that determines whether or not it appears?
If I apply the Graph API opt-out after the phase 1 changes have applied, will it disable the system-managed passkey profile? I think I've seen people say the answer to this is yes, but would like to confirm.
Lastly, is there anything else that's "special" about this system-managed passkey profile, or can you effectively just think of it as exactly the same as having the default profile with no restrictions enabled?
Why am I getting error code 100014 when accessing https://admin.cloud.microsoft? The error says, “Login is not supported for consumer users without business presence.” I am using an Azure for Students subscription and a Microsoft Entra ID Free tenant. Is this issue occurring because I am using a personal Microsoft account, or do I need to configure any additional permissions or licenses to access the Microsoft 365 Admin Center? How can I resolve this issue?
Just seeing if anyone else has this issue. When using the tenant switcher to connect to another O365 tenancy with a GDAP relationship, under Admin Centres we have no Identity shortcut to get us into Entra.
It shows when i'm in my tenancy and i can connect to their Entra portal when using my credentials and the direct link like the below: https://entra.microsoft.com/<Customer Name>.onmicrosoft.com
Does anyone else have this issue? Microsoft's first line have said this is wither by design or a UI issue.
Security Defaults help protect your tenant with baseline safeguards such as requiring MFA, blocking legacy authentication, and more. Until now, all these protections were managed through a single on/off setting. If you needed to disable a specific protection, you had to turn off the entire baseline, losing the other protections too.
That’s changing now!
Microsoft is introducing individual Security Defaults protections that split the existing single toggle into four Microsoft-managed rules. Admins can review each rule's scope and turn individual protections on or off without disabling the others.
The four rules include:
Require MFA for administrators
Require MFA for all users
Block legacy authentication
Block device code flow
The updated experience is currently in private preview for selected Microsoft Entra ID Free tenants. Eligible tenants will receive an invitation to access the preview.
Our users connect in via VPN, authentication with their Entra account and then mfa using Duo.
They also have their own mobile devices which they access email / OneDrive / SharePoint etc on - we lock these down with app protection policies so they can't screenshot / copy data out etc.
Business wants to prevent people connecting and spoofing their location, using commercial vpn's like Nord.
I've tried using defender for cloud apps, but on my first attempt using Proton VPN, it did not tag the IP as an anonymiser / VPN, so the solution doesn't give me much hope.
I can sign up to a service that gives us commercial VPN ranges, and add those to named locations in Entra, but the limit is 2000 addresses, which isn't feasible. Plus the addresses change all the time.
Hello my fellow Identity people! The r/ActiveDirectory community has a couple of events coming up, and you're welcome at both.
But wait, this is the Entra subreddit!
I am a firm believer that AD and Entra should be spoken of in the same sentence. Hybrid is the future. Hybrid is the path forward. So rather than fighting each other, let's work together.
Our meetups try to keep it to as little sales and marketing as possible (right now zero). It's just identity people doing identity things.
Tomorrow: Open Q&A
No agenda and no registration. Bring a question or just listen in.
When: October 16, 2026 @ 10:00 CT (UTC-5) / 15:00 UTC - 60 minutes
Starting November 4, users without an admin role can create agent identity blueprints. Whoever creates one becomes the owner, manages its credentials and can spin up agent identities from it.
Your user consent settings are the only thing deciding what those agents can reach.
Is that a default you want? I wrote up how to turn it off and find existing blueprints.
Currently I’m managing a tenant with 60+ subscriptions in Azure.
We operate in the following way:
- Separate cloud only admin
- No standing privileges on admin accounts
- No direct assignments on users, only security groups (exception for break glass accounts)
Currently we use Role Assignable Groups in combination with PIM, so if Admin A needs to get Owner permission on a subscription, he can PIM (because of eligible assignment) to a security group that is actively assigned to the Owner role on that subscription.
At the moment we’re rapidly approaching the limit of 500 role assignable groups within a tenant. The main goal of having these role assignable is to limit who can modify these security groups (such as group administrators).
We tried using RMAU’s to secure these groups, we got it working with PIM but only with active assignments.
My main question is, how should we continue?
I want to limit which security principles can modify security groups used in Azure in some way.
Some possible options I’m thinking of:
- RMAU in combination with access packages
- Switch to RMAU and permanent assignments in the groups but eligible in Azure
