Microsoft Entra ID Authentication Request Types
Hello! I'm currently investigating Microsoft Entra ID sign-in logs and would like to understand the following authentication request types: CredentialAuthenticationController:UnifiedPlatformCredentialChallenge RiskPhoneVerify:AcmaRiskPhoneVerify I have searched the available Microsoft documentation but haven't found references that explicitly explain these identifiers. I'd like to ask for some help to clarify the following: What do these request types represent? What authentication processes or security mechanisms trigger them? Are these expected during normal user authentication, MFA, or risk-based verification? Do these events indicate an authentication challenge, an actual credential submission, or a verification attempt? Is there any official Microsoft documentation or reference explaining these identifiers? My objective is to properly interpret these events during security monitoring and avoid incorrectly classifying legitimate authentication activity as suspicious. Any technical references or clarification would be greatly appreciated. Thank you!Entra ID - Federation or EAM for Passkey deployment
Question for the community: Looking to replace Entra to ADFS federation and also implement passkey. Have an existing deployment with a third party MFA provider. I want to limit the disruption for my end users as much as possible and am looking at 2 possible paths forward: Replace ADFS with third party, allowing Passkey and push from the third party, as well as first factor auth. Move to Entra staged rollout with EAM and have Entra deal with first factor. I know this wont include the ability to use third party first factor. Issues I am seeing is that the system browser setting needs to be enabled on the tenant and cant enforce external auth strengths in entra conditional access. All roads keep leading back to Entra which is fine with me but I do not currently have a P2 license for the advanced risk analytics. My third party currently has that capability. Would also love to know any rumblings of authentication strenght support for External MFA. What are some of the configurations out there that you all are doing and any pros/cons of each.
Synced iCloud Keychain passkey registration succeeds despite Device-Bound-only passkey profile
a { text-decoration: none; color: #464feb; } tr th, tr td { border: 1px solid #e6e6e6; } tr th { background-color: #f5f5f5; } We have Microsoft Entra passkeys enabled only for a pilot group. The assigned Default Passkey Profile is configured as: Passkey Type = Device-bound Key Restrictions enabled Microsoft Authenticator iOS and Android AAGUIDs only Despite this, a pilot account successfully registered a synced iCloud Keychain passkey. The Security Info page explicitly shows: "Passkey (Synced) - iCloud Keychain" The tenant also displays a warning banner stating: "All users enabled for SMS or voice authentication are in scope for passkey auto-enablement and will be assigned to a system-managed passkey profile that allows all passkey types without restrictions." Can Microsoft explain how tenant-managed passkey profiles interact with the system-managed passkey auto-enablement profile? Is the system-managed profile overriding or supplementing tenant-defined passkey restrictions?Passkey/FIDO2 for users in mainland China – recommended approach?
Hi, We are currently evaluating the adoption of Passkey/FIDO2 in Microsoft Entra ID as part of our strategy to move users away from traditional authentication methods such as SMS and voice and towards phishing-resistant authentication. Our Microsoft Entra ID tenant is a global tenant (not Azure China operated by 21Vianet), but we have a group of users who are physically located in mainland China. For users in other regions, we are evaluating Passkeys in Microsoft Authenticator and FIDO2 security keys. However, before defining the approach for our users in China, we would like to better understand the supported and recommended architecture for this particular scenario. We have reviewed the Microsoft documentation and understand that: Passkeys are not available for Microsoft Azure operated by 21Vianet. On iOS, Microsoft Authenticator Passkeys can be used to sign in to global organizations while the user is in China. On Android, Passkey authentication has dependencies such as Google Play Services, which raises questions for devices operating in mainland China. Our main questions are: For users physically located in mainland China but authenticating against a global Microsoft Entra ID tenant, what is Microsoft's recommended approach for deploying phishing-resistant authentication with Passkey/FIDO2? Is Microsoft Authenticator Passkey on iOS considered a fully supported option for users permanently located in mainland China, rather than only users temporarily traveling there? For Android users in mainland China, what is the recommended approach considering the dependency on Google Play Services? Is Passkey in Microsoft Authenticator a realistic supported option in this scenario? Would physical FIDO2 security keys be the preferred or more consistent alternative for users in China when mobile Passkeys cannot be reliably used? Are there any other Microsoft-supported Passkey providers or authentication approaches that should be considered specifically for mainland China? From an enrollment perspective, what would be the recommended bootstrap process for these users? For example, would Temporary Access Pass (TAP) be the recommended method to allow users to register their Passkey/FIDO2 credential before SMS/Voice is removed? Are there any additional regional, connectivity, mobile OS, or application compatibility considerations that should be taken into account before enforcing a phishing-resistant Authentication Strength through Conditional Access? Our objective is not simply to enable Passkey in the tenant, but to define a supported and sustainable authentication model for users located in mainland China before starting a broader rollout. Any experience, Microsoft guidance, or recommended architecture for this type of scenario would be greatly appreciated. Thanks in advance.
Trying to get support in reseting Authenticator MFA
Hello! We are locked out of our tenant's admin center as our authenticator installed device has been reset by mistake. I contacted our call MS service phone number (211 18 13 880) in Greece, but the AI bot is unable to record the case as it cannot vocally identify the admin user account and domain of our tenant, finally it terminates the call. There is no direct contact email or phone to human support from the data protection team. How are we supposed to handle this case further? .
Entra ID 53003: How to identify primary authentication when Authentication Details are empty?
We are investigating repeated interactive Microsoft Entra ID sign-ins with the following pattern: - ErrorCode: 53003 (BlockedByConditionalAccess) - isInteractive: true - AppDisplayName: OfficeHome - Authentication requirement: Multifactor authentication Conditional Access correctly blocks these requests because they originate outside our trusted locations. We have already confirmed through controlled testing that the authentication flow can reach 53003 after the correct credentials are provided. Our current problem is different: We need to determine what mechanism satisfied the primary/first authentication factor for the observed 53003 events. For these events, Authentication Details are empty: - Authentication method: empty - Authentication method detail: empty - Result detail: empty Therefore, we cannot determine whether primary authentication was performed using a password, an existing token/session claim, PHS, PTA, federation, Seamless SSO, or another mechanism. Our questions are: 1. Is there any tenant-visible telemetry that can identify the primary authentication mechanism when AuthenticationDetails is empty? 2. Can fields such as AuthenticationProcessingDetails, AuthenticationProtocol, IncomingTokenType, OriginalTransferMethod, or AuthenticationMethodsUsed reliably distinguish between password validation and reuse of an existing authentication/token? 3. If additional authentication infrastructure is used: - can PTA Authentication Agent logs be correlated using RequestId or CorrelationId? - should Seamless SSO generate a corresponding Kerberos 4769 event for AZUREADSSOACC$? - should federated authentication be traceable in AD FS logs? 4. For Password Hash Synchronization, is there any tenant-visible telemetry confirming that Entra ID actually validated the password for a specific sign-in request? 5. If this information is not exposed to the tenant, can Microsoft Support retrieve backend authentication telemetry for a specific Sign-in ID / RequestId / CorrelationId and determine how primary authentication was satisfied? Our goal is not to determine why Conditional Access generated 53003 — that part is already understood. We specifically need to identify what satisfied primary authentication before the Conditional Access evaluation.
Free, offline tool: see each user's real passkey policy in Entra ID and who SMS retirement blocks
Entra combines passkey profiles as a union (any profile that allows a passkey type wins), while Conditional Access works as an intersection. So a Global Admin in a strict "security keys only" profile who is also in an All Users profile can still register a synced iCloud or Google passkey, and the portal never shows you that per user. I built EffectivePasskey to answer three questions for every user and admin: 1. What passkey can this person actually register? 2. What can this admin actually sign in with after Conditional Access? 3. Who gets blocked when SMS and voice MFA retire (1 Feb 2027, and 1 Jul 2027 for Global Admins)? It runs entirely on your machine from read-only JSON exports. It never signs in to your tenant and never changes anything. No telemetry. MIT licensed and completely free. Try it with the included demo tenants: pip install effective-passkey GitHub: https://github.com/xsignon-secure/EffectivePasskey Feedback and issues are very welcome, especially from anyone mid-rollout.Security Info blocked by conditional access
Hello, We have a conditional access policy in place where a specific group can only access Microsoft 365 (deny all apps, except Office 365). The moment a user clicks on Security Info in My Account, the user is blocked by this policy. I cant find a way to exclude the app "My Signins" (AppId 19db86c3-b2b9-44cc-b339-36da233a3be2). Since MFA is forced for this group, they can't change their authenticator app registration. Is there a solution for this? Initial MFA setup works by the way. UPDATE jan 23, 2025: I contacted Microsoft support and this was their answer (in short): " MySignin is a very sensitive resource that is not available in the picker and cannot be excluded in the conditional access policy. Also, the application is calling Microsoft Graph. I understand that this is not the information you are looking to hear at this time, I would have loved to help but the application cannot be excluded from the policy. "
Locked account due to many attempts from malicious IP
Hello experts, today, a user contacted me that she cannot access M365 and asked to unlock her account. 1st thing I've checked were her log-ins in MS Entra and there I've found many and many attempts to log in from different countries - like India, Russia, Demark etc... that happened with just few seconds delay.... As a result, the user's account got blocked. Had to deal 1st time with this kind of issue.... See pictures below. Now, it looks like there was another user under the same attack few days ago (who is on vacation so doesnt know he is blocked for now :)).... Anyway, wondering - how I can prevent these types of attack? We have MFA (app auth) configured so even if the password got broken, MFA should prevent the attacker to sign in. I was going to create a conditional access but there are countries like Italy, Denmark (and other EU ones) etc that I don't want to block. We have M365 E3 with M365 E5 Security subscriptions assigned to all users. Would be grateful for any advise.Looking for an on-prem MFA solution for Active Directory and RDP
Hi everyone, We're reviewing options for adding MFA to our on-premises Active Directory environment. Most of our users authenticate with Active Directory, while administrators also use RDP for managing Windows servers. Because part of our infrastructure is isolated from the Internet, we'd prefer an on-premises MFA solution instead of relying on a cloud-only service. Has anyone implemented something similar recently? I'm interested in hearing: Which solution did you choose? How difficult was the deployment? Did you run into any compatibility or performance issues? Is there anything you'd do differently if you were deploying it again? Any real-world experience or recommendations would be greatly appreciated. Thanks!
