Windows Hello passkeys dialog appearing and cannot remove or suppress it.
Hi everyone, I’m dealing with a persistent Windows Hello and passkey issue in Chrome and Brave and yes this is relevant as they're the only browsers having this issue whilst Edge for example is fine, and at this point I’m trying to understand whether this is expected behavior, a bug, or a design oversight. PS. Yes, I'm in contact with related browser support teams but since they seem utterly hopeless i'm asking here, since its at least partially Windows Hello issue. Problem description Even with: Password managers disabled in browser settings, Windows Hello disabled in Chrome/Brave settings, Windows Hello PIN enabled only for device login, Passkeys still stored under chrome://settings/passkeys (which I cannot delete since its used for logging on the device), The devices are connected to Entra ID but this is not required to reproduce the issue although a buisness account configuration creates a Passkey with Windows Hello afaik. Observed behavior When I attempt to sign in on office.com, Windows Hello automatically triggers a dialog offering authentication via passkeys, even though: I don’t want passkeys used for browser logins, passkeys are turned off everywhere they can be, Windows Hello is intended only for local device authentication. The dialog cannot be suppressed, disabled, or hidden(trust me, i tried for weeks). It effectively forces the Windows Hello prompt as a primary option, which causes problems both personally and in business contexts (wrong credential signaling, misleading users that are supposed to use a dedicated password manager solution insted of browser password managers, enforcing an unwanted authentication flow, etc.). What I already verified Many, many, (too many) Windows registry workarounds that never worked. Dug through almost all flags on those browsers. Chrome/Brave → Password Manager: disabled Chrome/Brave → Windows Hello toggle: off Looked through what feels like almost every related option in Windows Settings. Tried gpedit.msc local rules System up to date Windows Hello configured to use PIN, but stores "passkeys used to log on to this device" Why this is a problem Windows Hello automatically assumes that the device-level Windows Hello credentials should always be available as a WebAuthn authenticator. This feels like a big security and UX issue due to: unexpected authentication dialogs, Inability to controll where and how passkey credential are shared to applications, inability to turn the feature off, no administrative or local option to disable Hello for WebAuthn separately from device login. Buisness users either having issues with keeping passwords in order (our buissnes uses a dedicated Password Manager but this behaviour covers its dialog option) or not having PIN to their devices (when I disable windows hello entierly, since when there is no passkeys the option doesn't appear) Questions Is there any supported way to disable Windows Hello as a WebAuthn/passkey option in browsers, while keeping Hello enabled for local device login? Is this expected behavior from the Windows Hello, or is it considered a bug? Are there registry/policy settings (documented or upcoming) that allow disabling the Windows platform authenticator specifically for browsers like Chrome and Brave? Is Microsoft aware of this issue? If so, is it tracked anywhere? Additional notes This issue replicates 100% across (as long as there are passkeys configured): Windows 11 devices i've managed to get my hands on, Chrome and Brave (latest versions), multiple Microsoft accounts and tenants, multiple clean installations. Any guidance or clarification from the Windows security or identity teams would be greatly appreciated. And honestly if there is any more info i could possibly provide PLEASE ask away.
Never Get Locked Out: The Importance of a Break Glass Admin Account
One of the simplest but most critical safeguards in Microsoft Entra ID is having a Break Glass Admin account. In my lab, I created a dedicated emergency account with: - Permanent Global Admin role (for emergencies only) - Excluded from Conditional Access policies - Strong password stored securely - Monitoring in place to detect any sign-in attempts This account is never used for daily operations — it exists only to guarantee access in case Conditional Access, MFA, or identity protection policies block all other admins. This setup prevents accidental lockouts and ensures continuity. Does your organization maintain a Break Glass Admin account, and how do you secure it?
Hunting for MFA manipulations in Entra ID tenants using KQL
The following article, Hunting for MFA manipulations in Entra ID tenants using KQL proved to be an invaluable resource in my search for an automated way to notify users of MFA modifications. I've adapted the KQL query to function within Defender Advanced Hunting or Azure Entra, my objective is to establish an alert that directly E-Mails the affected user, informing them of the MFA change and advising them to contact security if they did not initiate it. While the query runs correctly under Defender Advanced Hunting, I'm currently unable to create a workable custom alert because no "ReportId" is being captured. Despite consulting with Copilot, Gemini, CDW Support, and Microsoft Support, no workable solution has been achieved. Any insight would be greatly appreciated - Thank You! //Advanced Hunting query to parse modified: //StrongAuthenticationUserDetails (SAUD) //StrongAuthenticationMethod (SAM) let SearchWindow = 1h; let AuthenticationMethods = dynamic(["TwoWayVoiceMobile","TwoWaySms","TwoWayVoiceOffice","TwoWayVoiceOtherMobile","TwoWaySmsOtherMobile","OneWaySms","PhoneAppNotification","PhoneAppOTP"]); let AuthenticationMethodChanges = CloudAppEvents | where ActionType == "Update user." and RawEventData contains "StrongAuthenticationMethod" | extend Target = tostring(RawEventData.ObjectId) | extend Actor = tostring(RawEventData.UserId) | mv-expand ModifiedProperties = parse_json(RawEventData.ModifiedProperties) | where ModifiedProperties.Name == "StrongAuthenticationMethod" | project Timestamp,Actor,Target,ModifiedProperties,RawEventData,ReportId; let OldValues = AuthenticationMethodChanges | extend OldValue = parse_json(tostring(ModifiedProperties.OldValue)) | mv-apply OldValue on (extend Old_MethodType=tostring(OldValue.MethodType),Old_Default=tostring(OldValue.Default) | sort by Old_MethodType); let NewValues = AuthenticationMethodChanges | extend NewValue = parse_json(tostring(ModifiedProperties.NewValue)) | mv-apply NewValue on (extend New_MethodType=tostring(NewValue.MethodType),New_Default=tostring(NewValue.Default) | sort by New_MethodType); let RemovedMethods = AuthenticationMethodChanges | join kind=inner OldValues on ReportId | join kind=leftouter NewValues on ReportId,$left.Old_MethodType==$right.New_MethodType | where Old_MethodType != New_MethodType | extend Action = strcat("Removed (" , AuthenticationMethods[toint(Old_MethodType)], ") from Authentication Methods.") | extend ChangedValue = "Method Removed"; let AddedMethods = AuthenticationMethodChanges | join kind=inner NewValues on ReportId | join kind=leftouter OldValues on ReportId,$left.New_MethodType==$right.Old_MethodType | where Old_MethodType != New_MethodType | extend Action = strcat("Added (" , AuthenticationMethods[toint(New_MethodType)], ") as Authentication Method.") | extend ChangedValue = "Method Added"; let DefaultMethodChanges = AuthenticationMethodChanges | join kind=inner OldValues on ReportId | join kind=inner NewValues on ReportId | where Old_Default != New_Default and Old_MethodType == New_MethodType and New_Default == "true" | join kind=inner OldValues on ReportId | where Old_Default1 == "true" and Old_MethodType1 != New_MethodType | extend Old_MethodType = Old_MethodType1 | extend Action = strcat("Default Authentication Method was changed to (" , AuthenticationMethods[toint(New_MethodType)], ").") | extend ChangedValue = "Default Method"; let AuthenticationMethodReport = union RemovedMethods,AddedMethods,DefaultMethodChanges | project Timestamp,Action,Actor,Target,ChangedValue,OldValue=case(isempty(Old_MethodType), "",strcat(Old_MethodType,": ", AuthenticationMethods[toint(Old_MethodType)])),NewValue=case(isempty( New_MethodType),"", strcat(New_MethodType,": ", AuthenticationMethods[toint(New_MethodType)])); let AuthenticationDetailsChanges = CloudAppEvents | where ActionType == "Update user." and RawEventData contains "StrongAuthenticationUserDetails" | extend Target = tostring(RawEventData.ObjectId) | extend Actor = tostring(RawEventData.UserId) | extend ReportId= tostring(RawEventData.ReportId) | mvexpand ModifiedProperties = parse_json(RawEventData.ModifiedProperties) | where ModifiedProperties.Name == "StrongAuthenticationUserDetails" | extend NewValue = parse_json(replace_string(replace_string(tostring(ModifiedProperties.NewValue),"[",""),"]","")) | extend OldValue = parse_json(replace_string(replace_string(tostring(ModifiedProperties.OldValue),"[",""),"]","")) | mv-expand NewValue | mv-expand OldValue | where (tostring( bag_keys(OldValue)) == tostring(bag_keys(NewValue))) or (isempty(OldValue) and tostring(NewValue) !contains ":null") or (isempty(NewValue) and tostring(OldValue) !contains ":null") | extend ChangedValue = tostring(bag_keys(NewValue)[0]) | extend OldValue = tostring(parse_json(OldValue)[ChangedValue]) | extend NewValue = tostring(parse_json(NewValue)[ChangedValue]) | extend OldValue = case(ChangedValue == "PhoneNumber" or ChangedValue == "AlternativePhoneNumber", replace_strings(OldValue,dynamic([' ','(',')']), dynamic(['','',''])), OldValue ) | extend NewValue = case(ChangedValue == "PhoneNumber" or ChangedValue == "AlternativePhoneNumber", replace_strings(NewValue,dynamic([' ','(',')']), dynamic(['','',''])), NewValue ) | where tostring(OldValue) != tostring(NewValue) | extend Action = case(isempty(OldValue), strcat("Added new ",ChangedValue, " to Strong Authentication."),isempty(NewValue),strcat("Removed existing ",ChangedValue, " from Strong Authentication."),strcat("Changed ",ChangedValue," in Strong Authentication.")); union AuthenticationMethodReport, AuthenticationDetailsChanges | extend AccountUpn = Target | where Timestamp > ago(SearchWindow) //| summarize count() by Timestamp, Action, Actor, Target, ChangedValue, OldValue, NewValue, ReportId, AccountDisplayName, AccountId, AccountUpn | summarize arg_max(Timestamp, *) by Action | project Timestamp, Action, Actor, Target, ChangedValue, OldValue, NewValue, ReportId, AccountDisplayName, AccountId, AccountUpn | sort by Timestamp desc
User app registration - exploitable for BEC?
Hello. Recently dealt with a case of BEC. I'm not trained in forensics, but doing my best. Appears the hacker used an application called eM Client for their attack, getting access to a user's mailbox and hijacking a thread. I can see the login from two weeks ago (the incident was only noticed a couple days ago, however) - from a European country that SHOULD have been blocked by Conditional Access. Come to find out, the tenant conditional access was unassigned from everyone. We're not sure how - we re-enabled it, and audited changes, but the only change that appears was us re-enabling it. Which I thought indicates it was never configured right, except we've got a ticket documenting a change to Conditional Access a couple days after the hack that ALSO does not appear in the logs. So... it's likely it was changed, yet I have no record of that change (atleast, not through Entra > Monitoring > Auditing). If anyone knows any other ways of checking this, please advise - but I can't seem to even access our Diagnostic settings, the page tells me I need an Azure Active Directory subscription (I'm on Entra ID P1, which includes AAD.... this might be related to being global admin, and not Security Admin - we don't use that role in this relationship) ANYWAY, my amateur forensic skills have found that the attacker used an app called eM Client to get access. I'm not sure yet how they obtained the password, and got past MFA... But quick research shows this application (esp it's pro version) is known for use in BEC. The app was registered in Entra, and granted certain read permissions in Entra ID for shared mailboxes, presumably to find a decent thread to hijack. I'm not 100% sure yet there was any actual exploit done using this app, but it's popularity amongst hackers implies it does SOMETHING useful (i think remember that it authenticates using Exchange Web Services instead of Exchange Online, or something similar? Will update when I have the chance to check). We're in the process of improving our Secure Score, and this incident makes me think user's ability to register apps should be locked down. Checked Secure Score for this, and while there ARE recommendations around apps, disabling user app registration is NOT one of them. Just curious about people's thoughts. I just barely understand App Registration in Entra, but if this is a known attack vector, I would think disabling app registration would be a security recommendation?
Cannot login to Service Trust Portal
Hi, I'm trying to get some certificates from the service trust portal, but I keep getting "Service Trust Portal no longer support Microsoft Account (MSA) access." I'm using an account registered on Azure and I checked the Azure Active Directory, and the user exists (seeing it's the owner of the account). What am I missing here?Anomalies with Conditional Access Policy "Terms of Use" Failures
Hello Microsoft Community, I'm reaching out with a bit of a puzzle regarding our "Terms of Use" Conditional Access policy, and I'm eager to tap into the collective wisdom here for some insights. In our Entra ID User Sign-In logs, we've identified intermittent "failure" entries associated with the "Terms of Use" Conditional Access policy. Interestingly, even for users who had previously accepted the "Terms of Use". There appears to be no discernible impact, and they continue their tasks without interruption. This observation became apparent during the troubleshooting of unrelated Surface Hub and Edge Sync issues at some client sites. What adds to the complexity of the situation is that for the same users, both before and after these "failure" entries, the Conditional Access policy is marked as "success". Hence, it doesn't seem to be a straightforward case of the policy erroneously detecting non-acceptance of the "Terms of Use". The mystery lies in understanding why these intermittent "failure" entries occur for users who have already accepted the terms, especially when the policy consistently reports "success" for the same users. Furthermore, the Insights for the "Terms of Use" Conditional Access policy show around 1.48k successes and 1.43k failures in the last 90 days, yet there's no discernible impact on user functionality. Observations: "Failure" entries in Sign-In logs don't seem to disrupt users' day-to-day activities. The ratio of successes to failures is balanced, yet users experience no noticeable problems. The issue complicates troubleshooting efforts but doesn't significantly affect the user experience. I'm turning to the community for guidance on interpreting and resolving this discrepancy between "failure" entries in the Conditional Access policy logs and the seemingly unaffected user experience. Any insights into why these failures occur without user impact would be greatly appreciated. For additional context, I've attached screenshots of a user's Sign-In log entry and the insight chart from the Conditional Access policy. Sign-In log of a user (failure): Sign-In log of same user (success): Current Conditional Access insights: Thank you in advance for your time and assistance. I look forward to any guidance or solutions you can provide. Best regards, Leon Tüpker
Insider Builds
I have been an avid Microsoft user for many years with only a couple of small issues every now and again. The 6 weeks have been unbelievably stressful and disheartening. I thought trying samples of New Insider builds and enlisting in Azure for some up to date training for myself to help with what I wanted to roll out for my business. This has been the worst experience i have ever been apart of. I now have multiple computers and hardware in disarray but more importantly the loss of time and patience is paramount . I have come to realise the repetitive responses and requests for data collection on feedback or issues is one-sided The amount of user data submissions is not the issue though. It is the assistance from Microsoft regarding issue via portals, help-desk etc. The inclusion of many backend functions for the purpose of better user experience is heavily flawed. Unless end-user inadvertently has or encounters issues in there OS life is good. Heavily automated program tiggers sit through all OS builds for example. One drive. Regardless whether this is declined or removed it will always be running in the background. If you system had been compromised this is a perfect place for root-kit other Malware to spread. Xcopy: A Microsoft background function which has the ability clone and copy 99% of drivers of operating info structure. Can be controlled by ghost script directives or embedded dll to aid malware. Anti-virus or defender find difficulties identifying or distinguishing authentic and re-pro-ducted data. In time this type of incursion can mimic a vast amount of OS functionality. Microsoft OS validity. I have trailed numerous builds with all sharing this characteristic. Invalid or expired software and driver certificates & TPM flaws even after a full clean reset and TPM turned off in bios. Inevitably this can introduce compromised software without end-user knowledge. The impact leads to unauthorised access in many elements of the OS platform especially data access and embedded .dll which can run inline or above elevated authorisation. A lot of this is undetectable. Once embedded in OS and bios this is impossible to clean without expert assistance and can be very costly. For the most part the inclusion of new AI functionality across the OS platform is very welcomed. Unfortunately there are a large amount of bugs to be ironed out especially in the platform navigation. Advice provided via OS AI can be mis-leading or incorrect. .
SMTP XOAuth authentication and Microsoft authentication libraries
Due to the upcoming deprecation of basic authentication our company is looking to move all our products to modern authentication protocols for sending emails but we have some unusual usage scenarios that have me running in circles. I have been through all available documentation multiple times and I'm stuck. The problem is that we have on premise web applications that are running on multiple client servers and not a central location. This creates a problem when using standard OAuth flows since there is no fixed URL to use as a redirect URI. Because of this I have created a separate API on a fixed URL that will serve as the redirect URI for all clients and instances of our web applications. This breaks the standard usage of MSAL library and I had to go around chasing my tail to even be able to implement something that could possibly work. I have been able to do it using Microsoft.Identity.Client MSAL library but I hit a problem since I need to use the ConfidentialClientApp.AcquireTokenByAuthorizationCode call to redeem the access code obtained after user login but apparently SMTP does not allow confidential clients to login. We need the application to be able to send emails from any account any tenant or personal accounts. I have obtained the access token for a personal account but SMTP rejects it with this error: 535: 5.7.3 Authentication unsuccessful [AM8P251CA0016.EURP251.PROD.OUTLOOK.COM]. If I switch to PublicClientApplication then there is no AcquireTokenByAuthorizationCode method and I can't even use client secret so I'm not even sure how this works in redeeming a code. I am going by instructions on this page: https://docs.microsoft.com/en-us/exchange/client-developer/legacy-protocols/how-to-authenticate-an-imap-pop-smtp-application-by-using-oauth and it mentions no requirement of a public client application. It states I can use authorization code flow and the documentation on authorization code flow states it can be used by web apps and desktop apps. Well how am I supposed to use it when SMTP won't accept a confidential app and the PublicClientApplication does not have a method to redeem it? If I drop the authentication library and go for pure REST API call implementation, which application credentials should I use that the acquired tokens will be accepted by the SMTP server? Also I would like to know if office 365 users still have to disable security defaults and enable STMP Authentication to use SMTP with OAuth 2? This would defeat the whole purpose of migrating to OAuth 2 and the blog about deprecation states that moving to OAuth 2 is the way to prepare your app for this deprecation, but I've seen instructions on SMTP OAuth that state SMTP Authentication still needs to be enabled.
