Recent Discussions
BlackHat Community Interest Survey
Hey all! We’re planning Microsoft Security community circles, meetups, and AMA sessions during Black Hat week and would love your input on the topics and conversations most valuable to you. Please help us by filling out this form with your opinions (NO PERSONAL DATA COLLECTED): https://forms.cloud.microsoft/Pages/ResponsePage.aspx?id=v4j5cvGGr0GRqy180BHbR11eh_DyBlNCr6Pu5FQsI9ZUN1VQWTRDOTRZUVpQNEFLR05HMkg2RkFRTi4u Thank you!
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.
Critical identities in the Agent 365 era
From identity governance to execution control in the age of AI agents As organizations accelerate AI adoption, a fundamental shift is taking place in enterprise security: Identity is no longer just about access it is becoming the control plane. What started with user identities evolved into application and workload identities. Now, with AI agents entering the enterprise, we are entering a new phase: Every actor human, application or AI agent must be governed through identity. Why identity needs to evolve AI agents are no longer passive tools. They: Access enterprise data Trigger workflows Interact across systems Act autonomously This introduces a new reality: Security is no longer about who can log in It is about what is being executed, by which identity, in which context Introducing critical identities To address this, identity must evolve into a unified model: Critical identities = Human + Non-human + Agent identities Human identities — Employees, partners Non-human identities (NHIs) — Workloads, APIs, service principals Agent identities — AI agents powered by Entra Agent ID The next shift: a new identity plane Beyond users and applications, we now have: A third identity plane : Agent identities This identity type: Operates in its own execution context Acts autonomously Requires continuous governance Identity is no longer static It becomes contextual, behavioral and execution-driven The first principle: Converged identity is non-negotiable You cannot secure AI without converged identity This is not a priority. This is a prerequisite. Organizations must move from fragmented identity silos to: One unified identity fabric across all actors Where: Every identity is governed Every permission is controlled Every action is attributable Converged identity becomes the foundation of the agentic enterprise The next principle: AI SOC is no longer optional Your SOC must operate at machine speed not human speed This is not modernization. This is survival in an AI-led environment. In an AI-driven world: Events are continuous Signals increase exponentially Actions are autonomous SOC must evolve to: AI-powered, identity-aware and automation-driven operations Without it: Threats outpace detection Agents execute unnoticed Security becomes reactive AI SOC is not an enhancement it is the new operating model The next principle: Data security becomes the first line of defense Data not infrastructure is the primary risk surface AI agents: Aggregate enterprise data Generate new outputs Share insights dynamically Organizations must shift to: Protecting data in interaction not just at rest Without it: Sensitive data is exposed Agents amplify over-permissioned access Compliance breaks silently AI without data security is exposure not innovation The next principle: Agent 365 is the control plane for agents Agents must be governed as identities, not treated as background components Without governance: ❌ No visibility ❌ No ownership ❌ No lifecycle control Agent 365 delivers: Agent Registry → complete visibility Entra Agent ID → identity foundation Policy enforcement → Conditional Access + least privilege Lifecycle governance → full control Observability → execution tracking Without this: Agents act without accountability & Introducing Agent Inventory One view across identity, execution and control As AI scales, the challenge is no longer deployment: It is visibility into how identities behave Why Agent Inventory matters Traditional IAM answers: Who has access But now the real question is: Which identity is executing what, in which context, under which policy? What Agent Inventory surfaces Blueprints → Identity design layer Agent identities → Execution entities Agent users → Context (on-behalf-of) Orphan risk → Governance gaps Credential expiry → Identity hygiene Privilege gap analysis → Behavior vs access Registry gaps → Missing control plane coverage Action queue → Prioritized remediation Relationship graph → Identity + execution mapping What’s fundamentally new Traditional IAM Agentic IAM Identity = access Identity = execution control Static roles Context-aware permissions Identity lists Identity graphs Periodic review Continuous monitoring Bringing it all together When you step back and connect these capabilities, a clear pattern emerges. Identity becomes the foundation that governs every actor human, workload and agent while AI-powered SOC ensures detection and response can operate at the speed of execution. Data security establishes the guardrails, protecting what truly matters as agents interact with enterprise information. On top of this, Agent 365 provides the control plane bringing visibility, governance, and lifecycle management to every AI agent in the environment. And finally, Agent Inventory completes the picture by making identity and execution observable, helping organizations understand not just what exists, but how it behaves. Together, these layers form a cohesive model one that enables organizations to move from fragmented security to a unified, identity-driven approach that is ready for the realities of the agentic enterprise. We are entering a new paradigm: Humans define intent Applications execute logic Agents drive autonomous actions And all of it is governed by identity. So, You can’t govern agents without understanding their identity. You can’t secure identity without understanding execution. Critical identities + Agent 365 + Agent Inventory establish the control plane for the agentic enterprise.Microsoft Sovereignty 2026: From Data Residency to Digital Control
Over the past few years, data sovereignty has evolved from a compliance checkbox to a board-level priority. What began as a discussion around where data is stored has now expanded to who controls it, who operates it and under which jurisdiction it is governed. As we move into 2026, Microsoft Sovereignty is no longer just a roadmap, it is actively shaping how enterprises design cloud and AI architectures, especially across regulated industries. Why Sovereignty Matters More Than Ever Organizations today are navigating a complex landscape: Increasing regulatory mandates (GDPR, NIS2, DORA) Rising geopolitical concerns around cross-border data access Accelerated adoption of AI, copilots, and agentic systems But what’s changing in 2026 is the scale of AI adoption: 1.3B AI agents expected by 2028 82% of organizations plan to integrate AI agents within 1–3 years 90% of developers will use AI-assisted coding tools This fundamentally shifts the sovereignty discussion: It’s no longer about protecting data, it’s about governing AI-driven decisions and automation. Sovereignty in the Age of AI Agents A critical insight emerging from the field: Not all AI workloads can run in public cloud environments. Some AI scenarios require sovereignty by design, especially when: Data must remain within national jurisdiction Operational access must be restricted Systems must continue functioning during disconnection or crisis Examples include: Government AI copilots for citizen services Defense systems requiring air-gapped AI Financial services with strict regulatory oversight Healthcare workloads with sensitive patient data AI strategies must now survive regulation, disruption and disconnection not just scale. Microsoft Sovereignty: A Multi-Layered Approach Microsoft’s approach to sovereignty is not a single feature it’s a comprehensive framework spanning infrastructure, operations, security and AI. At its core, Microsoft Sovereign Cloud introduces three key deployment models: 1. Sovereign Public Cloud Regional data boundaries and in-country processing Built-in sovereign controls at hyperscale AI model choice with localized processing 2. Sovereign Private Cloud (AI-Driven Evolution) This is where sovereignty is evolving the fastest in 2026. Runs on Azure Local + Microsoft 365 Local + Foundry Local Enables continuous operations in hybrid or disconnected environments Supports AI workloads with local inferencing and GPU acceleration This is no longer traditional on-prem it is cloud-grade AI deployed locally. 3. National Partner Clouds Operated by local entities Meets country-specific certifications Bridges global cloud and national regulations Sovereign AI: From Data Control to Full Lifecycle Control The biggest shift in 2026: Sovereignty is no longer just about data it’s about the entire AI lifecycle. Sovereign AI ensures: Data stays local and under customer authority AI systems operate even without connectivity Customers control model selection (proprietary, OSS or custom) This introduces a new dimension: Model Sovereignty + Operational Sovereignty + Infrastructure Sovereignty The Rise of Foundry Local: AI From Cloud to Edge One of the most important innovations enabling this shift is Microsoft Foundry Local. Foundry Local extends AI capabilities across: Cloud Edge devices On-premises environments Fully disconnected deployments This allows organizations to: Run models locally using containers Use Arc-enabled Kubernetes for deployment Maintain consistent governance across environments AI Models Under Sovereign Control Microsoft enables multiple AI model strategies: Models-as-a-Platform (MaaP) → Customer-managed Models-as-a-Service (MaaS) → Microsoft-managed BYO Models → Full flexibility (Open-source or proprietary) This means enterprises can shift from: ❌ Vendor-dependent AI ✅ Sovereign, customer-controlled AI ecosystems Sovereign AI Deployment Patterns Two dominant patterns are emerging: 1. Hybrid Sovereign AI Develop in cloud Deploy to edge or sovereign environments Maintain flexibility 2. Fully Disconnected AI Air-gapped environments No dependency on cloud connectivity Full local processing and inference This is critical for defense, public sector and critical infrastructure. The Reality Check: What Enterprises Must Still Own While Microsoft provides the platform, sovereignty is not “set and forget.” Organizations must still: Design region-first and sovereignty-aware architectures Implement governance across hybrid and disconnected environments Manage model lifecycle and inferencing policies locally Ensure compliance with evolving regulatory frameworks Sovereignty is now an architecture decision not just a cloud feature. My Perspective (Field Insight) From working with regulated customers (BFSI, telecom, public sector), I see three clear patterns: 1. Sovereignty is now directly tied to AI adoption → Customers will not scale GenAI without sovereign guarantees 2. Hybrid + Sovereign AI is becoming the default architecture → Cloud-only strategies are no longer sufficient 3. Control of models and inferencing is the new trust boundary → Trust is shifting from infrastructure to AI execution layers Final Thoughts: Sovereignty as an AI Enabler The narrative around sovereignty is shifting: ❌ Earlier: “Sovereignty restricts innovation” ✅ Now: “Sovereignty enables trusted AI at scale” Microsoft’s Sovereign Cloud strategy reflects this evolution bringing together: Cloud-scale capabilities Local control and resilience AI lifecycle governance The opportunity ahead is clear: Design sovereign-by-default AI architectures that are secure, compliant and built for resilience whether connected, hybrid or fully disconnected.Kerberos and the End of RC4: Protocol Hardening and Preparing for CVE‑2026‑20833
CVE-2026-20833 addresses the continued use of the RC4‑HMAC algorithm within the Kerberos protocol in Active Directory environments. Although RC4 has been retained for many years for compatibility with legacy systems, it is now considered cryptographically weak and unsuitable for modern authentication scenarios. As part of the security evolution of Kerberos, Microsoft has initiated a process of progressive protocol hardening, whose objective is to eliminate RC4 as an implicit fallback, establishing AES128 and AES256 as the default and recommended algorithms. This change should not be treated as optional or merely preventive. It represents a structural change in Kerberos behavior that will be progressively enforced through Windows security updates, culminating in a model where RC4 will no longer be implicitly accepted by the KDC. If Active Directory environments maintain service accounts, applications, or systems dependent on RC4, authentication failures may occur after the application of the updates planned for 2026, especially during the enforcement phases introduced starting in April and finalized in July 2026. For this reason, it is essential that organizations proactively identify and eliminate RC4 dependencies, ensuring that accounts, services, and applications are properly configured to use AES128 or AES256 before the definitive changes to Kerberos protocol behavior take effect. Official Microsoft References CVE-2026-25177 - Security Update Guide - Microsoft - Active Directory Domain Services Elevation of Privilege Vulnerability Microsoft Support – How to manage Kerberos KDC usage of RC4 for service account ticket issuance changes related to CVE-2026-20833 (KB 5073381) Microsoft Learn – Detect and Remediate RC4 Usage in Kerberos AskDS – What is going on with RC4 in Kerberos? Beyond RC4 for Windows authentication | Microsoft Windows Server Blog So, you think you’re ready for enforcing AES for Kerberos? | Microsoft Community Hub Risk Associated with the Vulnerability When RC4 is used in Kerberos tickets, an authenticated attacker can request Service Tickets (TGS) for valid SPNs, capture these tickets, and perform offline brute-force attacks, particularly Kerberoasting scenarios, with the goal of recovering service account passwords. Compared to AES, RC4 allows significantly faster cracking, especially for older accounts or accounts with weak passwords. Technical Overview of the Exploitation In simplified terms, the exploitation flow occurs as follows: The attacker requests a TGS for a valid SPN. The KDC issues the ticket using RC4, when that algorithm is still accepted. The ticket is captured and analyzed offline. The service account password is recovered. The compromised account is used for lateral movement or privilege escalation. Official Timeline Defined by Microsoft Important clarification on enforcement behavior Explicit account encryption type configurations continue to be honored even during enforcement mode. The Kerberos hardening associated with CVE‑2026‑20833 focuses on changing the default behavior of the KDC, enforcing AES-only encryption for TGS ticket issuance when no explicit configuration exists. This approach follows the same enforcement model previously applied to Kerberos session keys in earlier security updates (for example, KB5021131 related to CVE‑2022‑37966), representing another step in the progressive removal of RC4 as an implicit fallback. January 2026 – Audit Phase Starting in January 2026, Microsoft initiated the Audit Phase related to changes in RC4 usage within Kerberos, as described in the official guidance associated with CVE-2026-20833. The primary objective of this phase is to allow organizations to identify existing RC4 dependencies before enforcement changes are applied in later phases. During this phase, no functional breakage is expected, as RC4 is still permitted by the KDC. However, additional auditing mechanisms were introduced, providing greater visibility into how Kerberos tickets are issued in the environment. Analysis is primarily based on the following events recorded in the Security Log of Domain Controllers: Event ID 4768 – Kerberos Authentication Service (AS request / Ticket Granting Ticket) Event ID 4769 – Kerberos Service Ticket Operations (Ticket Granting Service – TGS) Additional events related to the KDCSVC service These events allow identification of: the account that requested authentication the requested service or SPN the source host of the request the encryption algorithm used for the ticket and session key This information is critical for detecting scenarios where RC4 is still being implicitly used, enabling operations teams to plan remediation ahead of the enforcement phase. If these events are not being logged on Domain Controllers, it is necessary to verify whether Kerberos auditing is properly enabled. For Kerberos authentication events to be recorded in the Security Log, the corresponding audit policies must be configured. The minimum recommended configuration is to enable Success auditing for the following subcategories: Kerberos Authentication Service Kerberos Service Ticket Operations Verification can be performed directly on a Domain Controller using the following commands: auditpol /get /subcategory:"Kerberos Service Ticket Operations" auditpol /get /subcategory:"Kerberos Authentication Service" In enterprise environments, the recommended approach is to apply this configuration via Group Policy, ensuring consistency across all Domain Controllers. The corresponding policy can be found at: Computer Configuration - Policies - Windows Settings - Security Settings - Advanced Audit Policy Configuration - Audit Policies - Account Logon Once enabled, these audits record events 4768 and 4769 in the Domain Controllers’ Security Log, allowing analysis tools—such as inventory scripts or SIEM/Log Analytics queries—to accurately identify where RC4 is still present in the Kerberos authentication flow. April 2026 – Enforcement with Manual Rollback With the April 2026 update, the KDC begins operating in AES-only mode (0x18) when the msDS-SupportedEncryptionTypes attribute is not defined. This means RC4 is no longer accepted as an implicit fallback. During this phase, applications, accounts, or computers that still implicitly depend on RC4 may start failing. Manual rollback remains possible via explicit configuration of the attribute in Active Directory. July 2026 – Final Enforcement Starting in July 2026, audit mode and rollback options are removed. RC4 will only function if explicitly configured—a practice that is strongly discouraged. This represents the point of no return in the hardening process. Official Monitoring Approach Microsoft provides official scripts in the repository: https://github.com/microsoft/Kerberos-Crypto/tree/main/scripts The two primary scripts used in this analysis are: Get-KerbEncryptionUsage.ps1 The Get-KerbEncryptionUsage.ps1 script, provided by Microsoft in the Kerberos‑Crypto repository, is designed to identify how Kerberos tickets are issued in the environment by analyzing authentication events recorded on Domain Controllers. Data collection is primarily based on: Event ID 4768 – Kerberos Authentication Service (AS‑REQ / TGT issuance) Event ID 4769 – Kerberos Service Ticket Operations (TGS issuance) From these events, the script extracts and consolidates several relevant fields for authentication flow analysis: Time – when the authentication occurred Requestor – IP address or host that initiated the request Source – account that requested the ticket Target – requested service or SPN Type – operation type (AS or TGS) Ticket – algorithm used to encrypt the ticket SessionKey – algorithm used to protect the session key Based on these fields, it becomes possible to objectively identify which algorithms are being used in the environment, both for ticket issuance and session establishment. This visibility is essential for detecting RC4 dependencies in the Kerberos authentication flow, enabling precise identification of which clients, services, or accounts still rely on this legacy algorithm. Example usage: .\Get-KerbEncryptionUsage.ps1 -Encryption RC4 -Searchscope AllKdcs | Export-Csv -Path .\KerbUsage_RC4_All_ThisDC.csv -NoTypeInformation -Encoding UTF8 Data Consolidation and Analysis In enterprise environments, where event volumes may be high, it is recommended to consolidate script results into analytical tools such as Power BI to facilitate visualization and investigation. The presented image illustrates an example dashboard built from collected results, enabling visibility into: Total events analyzed Number of Domain Controllers involved Number of requesting clients (Requestors) Most frequently involved services or SPNs (Targets) Temporal distribution of events RC4 usage scenarios (Ticket, SessionKey, or both) This type of visualization enables rapid identification of RC4 usage patterns, remediation prioritization, and progress tracking as dependencies are eliminated. Additionally, dashboards help answer key operational questions, such as: Which services still depend on RC4 Which clients are negotiating RC4 for sessions Which Domain Controllers are issuing these tickets Whether RC4 usage is decreasing over time This combined automated collection + analytical visualization approach is the recommended strategy to prepare environments for the Microsoft changes related to CVE‑2026‑20833 and the progressive removal of RC4 in Kerberos. Visualizing Results with Power BI To facilitate analysis and monitoring of RC4 usage in Kerberos, it is recommended to consolidate script results into a Power BI analytical dashboard. 1. Install Power BI Desktop Download and install Power BI Desktop from the official Microsoft website 2. Execute data collection After running the Get-KerbEncryptionUsage.ps1 script, save the generated CSV file to the following directory: C:\Temp\Kerberos_KDC_usage_of_RC4_Logs\KerbEncryptionUsage_RC4.csv 3. Open the dashboard in Power BI Open the file RC4-KerbEncryptionUsage-Dashboards.pbix using Power BI Desktop. If you are interested, please leave a comment on this post with your email address, and I will be happy to share with you. 4. Update the data source If the CSV file is located in a different directory, it will be necessary to adjust the data source path in Power BI. As illustrated, the dashboard uses a parameter named CsvFilePath, which defines the path to the collected CSV file. To adjust it: Open Transform Data in Power BI. Locate the CsvFilePath parameter in the list of Queries. Update the value to the directory where the CSV file was saved. Click Refresh Preview or Refresh to update the data. Click Home → Close & Apply. This approach allows rapid identification of RC4 dependencies, prioritization of remediation actions, and tracking of progress throughout the elimination process. List-AccountKeys.ps1 This script is used to identify which long-term keys are present on user, computer, and service accounts, enabling verification of whether RC4 is still required or whether AES128/AES256 keys are already available. Interpreting Observed Scenarios Microsoft recommends analyzing RC4 usage by jointly considering two key fields present in Kerberos events: Ticket Encryption Type Session Encryption Type Each combination represents a distinct Kerberos behavior, indicating the source of the issue, risk level, and remediation point in the environment. In addition to events 4768 and 4769, updates released starting January 13, 2026, introduce new Kdcsvc events in the System Event Log that assist in identifying RC4 dependencies ahead of enforcement. These events include: Event ID 201 – RC4 usage detected because the client advertises only RC4 and the service does not have msDS-SupportedEncryptionTypes defined. Event ID 202 – RC4 usage detected because the service account does not have AES keys and the msDS-SupportedEncryptionTypes attribute is not defined. Event ID 203 – RC4 usage blocked (enforcement phase) because the client advertises only RC4 and the service does not have msDS-SupportedEncryptionTypes defined. Event ID 204 – RC4 usage blocked (enforcement phase) because the service account does not have AES keys and msDS-SupportedEncryptionTypes is not defined. Event ID 205 – Detection of explicit enablement of insecure algorithms (such as RC4) in the domain policy DefaultDomainSupportedEncTypes. Event ID 206 – RC4 usage detected because the service accepts only AES, but the client does not advertise AES support. Event ID 207 – RC4 usage detected because the service is configured for AES, but the service account does not have AES keys. Event ID 208 – RC4 usage blocked (enforcement phase) because the service accepts only AES and the client does not advertise AES support. Event ID 209 – RC4 usage blocked (enforcement phase) because the service accepts only AES, but the service account does not have AES keys. https://support.microsoft.com/en-gb/topic/how-to-manage-kerberos-kdc-usage-of-rc4-for-service-account-ticket-issuance-changes-related-to-cve-2026-20833-1ebcda33-720a-4da8-93c1-b0496e1910dc They indicate situations where RC4 usage will be blocked in future phases, allowing early detection of configuration issues in clients, services, or accounts. These events are logged under: Log: System Source: Kdcsvc Below are the primary scenarios observed during the analysis of Kerberos authentication behavior, highlighting how RC4 usage manifests across different ticket and session encryption combinations. Each scenario represents a distinct risk profile and indicates specific remediation actions required to ensure compliance with the upcoming enforcement phases. Scenario A – RC4 / RC4 In this scenario, both the Kerberos ticket and the session key are issued using RC4. This is the worst possible scenario from a security and compatibility perspective, as it indicates full and explicit dependence on RC4 in the authentication flow. This condition significantly increases exposure to Kerberoasting attacks, since RC4‑encrypted tickets can be subjected to offline brute-force attacks to recover service account passwords. In addition, environments remaining in this state have a high probability of authentication failure after the April 2026 updates, when RC4 will no longer be accepted as an implicit fallback by the KDC. Events Associated with This Scenario During the Audit Phase, this scenario is typically associated with: Event ID 201 – Kdcsvc Indicates that: the client advertises only RC4 the service does not have msDS-SupportedEncryptionTypes defined the Domain Controller does not have DefaultDomainSupportedEncTypes defined This means RC4 is being used implicitly. This event indicates that the authentication will fail during the enforcement phase. Event ID 202 – Kdcsvc Indicates that: the service account does not have AES keys the service does not have msDS-SupportedEncryptionTypes defined This typically occurs when: legacy accounts have never had their passwords reset only RC4 keys exist in Active Directory Possible Causes Common causes include: the originating client (Requestor) advertises only RC4 the target service (Target) is not explicitly configured to support AES the account has only legacy RC4 keys the msDS-SupportedEncryptionTypes attribute is not defined Recommended Actions To remediate this scenario: Correctly identify the object involved in the authentication flow, typically: a service account (SPN) a computer account or a Domain Controller computer object Verify whether the object has AES keys available using analysis tools or scripts such as List-AccountKeys.ps1. If AES keys are not present, reset the account password, forcing generation of modern cryptographic keys (AES128 and AES256). Explicitly define the msDS-SupportedEncryptionTypes attribute to enable AES support. Recommended value for modern environments: 0x18 (AES128 + AES256) = 24 As illustrated below, this configuration can be applied directly to the msDS-SupportedEncryptionTypes attribute in Active Directory. AES can also be enabled via Active Directory Users and Computers by explicitly selecting: This account supports Kerberos AES 128 bit encryption This account supports Kerberos AES 256 bit encryption These options ensure that new Kerberos tickets are issued using AES algorithms instead of RC4. Temporary RC4 Usage (Controlled Rollback) In transitional scenarios—during migration or troubleshooting—it may be acceptable to temporarily use: 0x1C (RC4 + AES) = 28 This configuration allows the object to accept both RC4 and AES simultaneously, functioning as a controlled rollback while legacy dependencies are identified and corrected. However, the final objective must be to fully eliminate RC4 before the final enforcement phase in July 2026, ensuring the environment operates exclusively with AES128 and AES256. Scenario B – AES / RC4 In this case, the ticket is protected with AES, but the session is still negotiated using RC4. This typically indicates a client limitation, legacy configuration, or restricted advertisement of supported algorithms. Events Associated with This Scenario During the Audit Phase, this scenario may generate: Event ID 206 Indicates that: the service accepts only AES the client does not advertise AES in the Advertised Etypes In this case, the client is the issue. Recommended Action Investigate the Requestor Validate operating system, client type, and advertised algorithms Review legacy GPOs, hardening configurations, or settings that still force RC4 For Linux clients or third‑party applications, review krb5.conf, keytabs, and Kerberos libraries Scenario C – RC4 / AES Here, the session already uses AES, but the ticket is still issued using RC4. This indicates an implicit RC4 dependency on the Target or KDC side, and the environment may fail once enforcement begins. Events Associated with This Scenario This scenario may generate: Event ID 205 Indicates that the domain has explicit insecure algorithm configuration in: DefaultDomainSupportedEncTypes This means RC4 is explicitly allowed at the domain level. Recommended Action Correct the Target object Explicitly define msDS-SupportedEncryptionTypes with 0x18 = 24 Revalidate new ticket issuance to confirm full migration to AES / AES Conclusion CVE‑2026‑20833 represents a structural change in Kerberos behavior within Active Directory environments. Proper monitoring is essential before April 2026, and the msDS-SupportedEncryptionTypes attribute becomes the primary control point for service accounts, computer accounts, and Domain Controllers. July 2026 represents the final enforcement point, after which there will be no implicit rollback to RC4.
Defender Threat & Vulnerability Management Reporting
Hello, we're looking at implementing DTVM for our endpoints, but are curious about reporting. Is there a way we can get these reports in a PDF format, and scoped to specific devices only? I'd like to use the evidence paths gathered from KQL to help build the reports. Are there any guides or steps out there that shows how we can do this with tools like PowerBI? Thanks in advance.
BIT LOCKER RECOVERY
Greetings everyone, Recently Microsoft Windows forced into entering an update upon closing my laptop. After that I could not boot up without being asked to enter a Bit Locker Recovery key.I eventually found the correct key and entered it this morning successfully.Laptop was up and running ok or so I thought.Switched the laptop on just now and low and behold I have to put the Recovery key in again.!!I gather the problem arrived during the last update.I s there a fix for this or am I now having to put the key in every single time I switch the laptop on!! Is it possible to remove the faulty update? Many thanks for any help received Dave1950
Unsanctioned cloud apps generates constant alerts
When I mark a cloud app as unsanctioned it created a URL based indicator to block the site. However, it also by default enables the Generate Alert option on the indictor. This causes my SOC to bet inundated with garbage alerts. Now normally if I'm just unsanctioning one Cloud App a could go and turn of the alert. However, I use cloud app policy that will identify any new Cloud Apps in an entire category and then unsanction it. But it enables Generate Alert on the URL indicator. Then if someone accesses that new one the generate alert kicks off. I don't want to have to go into every new app and untick generate alert manually that's just too time consuming. Is there a way to change the default behaviour when adding an indicator to not enable the generate alert? Of is there some other way to do this? I could consider using power automate or something but I'd rather the default behaviour be the fix as automation can break. I don't have time to babysit it.
Feature Request: Extend Security Copilot inclusion (M365 E5) to M365 A5 Education tenants
Background At Ignite 2025, Microsoft announced that Security Copilot is included for all Microsoft 365 E5 customers, with a phased rollout starting November 18, 2025. This is a significant step forward for security operations. The gap Microsoft 365 A5 for Education is the academic equivalent of E5 — it includes the same core security stack: Microsoft Defender, Entra, Intune, and Purview. However, the Security Copilot inclusion explicitly covers only commercial E5 customers. There is no public roadmap or timeline for extending this benefit to A5 education tenants. Why this matters Education institutions face the same cybersecurity threats as commercial organizations — often with fewer dedicated security resources. The A5 license was positioned as the premium security offering for education. Excluding it from Security Copilot inclusion creates an inequity between commercial and education customers holding functionally equivalent license tiers. Request We would like Microsoft to: Confirm whether Security Copilot inclusion will be extended to M365 A5 Education tenants If yes, provide an indicative timeline If no, clarify the rationale and what alternative paths exist for education customers Are other EDU admins in the same situation? Would appreciate any upvotes or comments to help raise visibility with the product team.
Short survey: Feedback on Sensitivity Label Suggestions in Microsoft 365 Apps
Hi everyone, I’m looking to gather feedback on user experiences with Sensitivity Label suggestions in Microsoft 365 apps. This short survey aims to understand how label recommendations are working in practice and where improvements may be needed. Your responses will help identify common challenges and opportunities to make the label recommendation process more accurate, useful, and seamless for users. Survey link: Experience with Recommended Sensitivity Labels in Microsoft 365 – Fill out form The survey takes around 3 minutes to complete. Your feedback will directly help us better understand real-world experiences with label suggestions. Thank you very much for taking the time to contribute.Security Copilot Agents in Defender XDR: where things actually stand
With RSAC 2026 behind us and the E5 inclusion now rolling out between April 20 and June 30, anyone planning SOC workflows or sitting on a capacity budget needs to get a clear picture of what is GA, what is preview, and what was just announced. The marketing pages tend to blur those lines. This is my sober look at the current state, with the operational details that matter for adoption decisions. What is actually shipping right now The Phishing Triage Agent is GA. It only handles user-reported phish through Defender for Office 365 P2, but for most SOCs that is a meaningful chunk of the L1 queue. Verdicts come with a natural-language rationale rather than just a label, which is the part that determines whether analysts will trust it. The agent learns from analyst confirmations and overrides, so the feedback loop matters more than the initial setup. There is a setup detail that is easy to miss: the agent will not classify alerts that have already been suppressed by alert tuning. The built-in rule "Auto-Resolve - Email reported by user as malware or phish" needs to be off, and any custom tuning rules that touch this alert type need review. If you skip this, the agent runs on an empty queue and you wonder why nothing is happening. The Threat Intelligence Briefing Agent is also GA. It produces tenant-tailored intel briefings on a regular cadence. Useful, but lower operational impact than the triage agents. Copilot Chat in Defender went GA with the April 2026 update. Conversational Q&A inside the portal, grounded in your incident and entity data. This is the lowest-risk way to get value out of Security Copilot and probably where most teams should start. Public preview, worth watching The Dynamic Threat Detection Agent is the most technically interesting one. It runs continuously in the Defender backend, correlates across Defender and Sentinel telemetry, generates its own hypotheses, and emits a dynamic alert when the evidence converges. Detection source on the alert is Security Copilot. Each alert includes the structured fields (severity, MITRE techniques, remediation) plus a narrative explaining the reasoning. For EU tenants the residency point is worth confirming with whoever owns data protection in your org: the service runs region-local, so customer data and required telemetry stay inside the designated geographic boundary. During public preview it is enabled by default for eligible customers and is free. At GA, currently targeted for late 2026, it transitions to the SCU consumption model and can be disabled. The Threat Hunting Agent is also in public preview. Natural language to KQL with guided hunting. Lower stakes, but useful for teams without deep KQL expertise on hand. Announced at RSAC, still preview Two agents got the headlines in March: The Security Alert Triage Agent extends the agentic triage approach beyond phishing into identity and cloud alerts. The longer-term direction is consolidating phishing, identity, and cloud triage under a single agent. Rollout is from April 2026, in preview. The Security Analyst Agent is the multi-step investigation agent. Deeper context across Defender and Sentinel, prioritised findings, transparent reasoning trace. Preview since March 26. Both look promising on paper, but Microsoft's history of preview features that take a long time to mature is well-documented. I would not plan production workflows around either of them yet. What you actually get with the E5 inclusion This is the licensing change most people are dealing with right now. Security Copilot has been part of the E5 product terms since January 1, 2026. Tenant rollout is phased between April 20 and June 30, 2026, with a 7-day notification before activation. The numbers: 400 SCUs per month for every 1,000 paid user licenses Capped at 10,000 SCUs per month, which you hit at around 25,000 seats Linear scaling below that, so a 3,000-seat tenant gets 1,200 SCUs per month No rollover, the pool resets monthly What is included: chat, promptbooks, agentic scenarios across Defender, Entra, Intune, Purview, and the standalone portal. Agent Builder and the Graph APIs are in. If you also run Sentinel, the included SCUs apply to Security Copilot scenarios there. What is not included: Sentinel data lake compute and storage. Those still run through Azure on the regular meters. Beyond the included pool you pay 6 USD per SCU pay-as-you-go, with 30 days notice before that mode kicks in. Practical things worth knowing before activation A few details that are easy to miss in the docs: Under System > Settings > Copilot in Defender > Preferences, switch from Auto-generate to Generate on demand. Auto-generate will burn SCUs on incidents nobody is going to look at. Generate on demand gives you direct control. In the Security Copilot portal workspace settings, check the data storage location and the data sharing toggle. Data sharing is on by default, which means Microsoft uses interaction data for product improvement. If your compliance position does not allow that, change it before agents start running. Changing it requires the Capacity Contributor role. Agent runs are not equivalent to the same number of analyst chat prompts. A triage agent processing fifty alerts in one run consumes meaningfully more SCUs than fifty manual prompts on the same data. If you have a high-volume phishing pipeline, model that out before you flip the switch broadly. The usage dashboard in the Security Copilot portal breaks down consumption by day, user, and scenario. Output quality depends on telemetry quality. Flaky connectors, gaps in log sources, or a high baseline of misconfigured alerts will produce verdicts that match. Connector health monitoring (the SentinelHealth table in Advanced Hunting is a sensible starting point) is a precondition. The agents only improve if analysts feed the override loop. If your team treats the verdicts as background noise rather than confirming or correcting them, the feedback signal is lost and calibration stays where it shipped. That is a process problem, not a product problem, but it determines whether any of this is worth the SCUs. A reasonable adoption order A rough sequence that minimises capacity surprises: Copilot Chat in Defender first. Lowest risk, immediate value through natural language Q&A in the investigation context. Phishing Triage Agent on a controlled subset, with a review cadence in place. Check the built-in tuning rules first. Watch the SCU dashboard for the first month before adding anything else. Let the Dynamic Threat Detection Agent run while it is in public preview, since it is default-on and free anyway. Compare its alerts against existing Sentinel detections. Security Alert Triage Agent for identity and cloud once the phishing baseline is stable. Establish a monthly review covering agent decisions, false-positive rate, SCU cost, and MTTD/MTTR trends. Technically, agentic triage is moving past phishing into identity and cloud, and the Dynamic Threat Detection Agent represents a genuine attempt at the false-negative problem rather than just another rule engine. Lizenziell, the E5 inclusion removes the biggest barrier to adoption that previously existed. The risk is enabling everything at once. Agents that nobody reviews are agents that consume capacity without delivering value, and the SCU dashboard is the only thing that will tell you that is happening. One agent, one use case, a 30-day baseline, then the next one. The order matters more than the speed.Microsoft Authenticator help
keep getting Microsoft Authenticator attempts on my Hotmail account every 15 mins or so from an overseas location that im not aware of. I have changed my password, however im still getting attempts. I deny the request every time, and when i look at security section under my account > view my sign-in activity. it doesn't appear here .Copilot Studio Auditing
Hey team, While I'm doing research around copilot studio audting and logging, I did noticed few descripencies. This is an arcticle that descibes audting in Microsoft copilot. https://learn.microsoft.com/en-us/microsoft-copilot-studio/admin-logging-copilot-studio?utm_source=chatgpt.com I did few simualtions on copilot studio in my test tenant, I don't see few operations generated which are mentioned in the article. For Example: For updating authentication details, it generated "BotUpdateOperation-BotIconUpdate" event. Ideally it should have generated "BotUpdateOperation-BotAuthUpdate" I did expected different operations for Instructions, tools and knowledge update, I believe all these are currently covered under "BotComponentUpdate". Any security experts suggestion/thoughts on this?
VPN Integration not persistent
Hello, We tried to configure https://learn.microsoft.com/en-us/defender-for-identity/vpn-integration from supported Cisco VPN GW. We established the RADIUS Accounting logs to be sent to DC with MDI sensors installed. Yet when we enabled this in Defender Portal (Settings > Identities > VPN) by checking the box and inserting the shared secret, the configuration is not persistent. We hit save, and we are presented with the success green message, but once we refresh the page or go elsewhere in the portal, the checkbox is not checked. Has anyone encountered the same issue? Thanks, SimonClarification over "dormant" account status
I was looking today at our list of "Remove dormant accounts from sensitive groups" within Microsoft Defender for Identity, and one service account has caused a bit of discussion. The account would only be used on-premise and would never be carrying out authentications out of our estate. In this case would Defender for Identity still see the account as being "dormant", or is the reason because it's not carried out any of those off-estate authentications? Apologies if this is a simple question, but it would be very helpful to know the answer.Microsoft Entra Conditional Access Optimization Agent - Move from Static to Continuous Protection
Conditional Access has long been Microsoft Entra’s Zero Trust policy engine—powerful, flexible, and can easily go wrong with misconfiguration over time due to large volume of policies. As the no of tenants increase the no of new users and applications the new modern authentication methods are introduced continuously, and Conditional Access policies that once provided full coverage often drift into partial or inconsistent protection. This is an operational gap which introduces complexity and manageability challenges. The solution to this is utilizing Conditional Access Optimization Agent, an AI‑powered agent integrated with Microsoft Security Copilot that continuously evaluates Conditional Access coverage and recommends targeted improvements aligned to Microsoft Zero Trust best practices. In this article, Let us understand what problem the agent can solve, how it works, how it can be best utilized with the real‑world Entra Conditional Access strategy. The Problem is Conditional Access does not break loudly Most Conditional Access issues are not caused by incorrect syntax or outright failure. Instead, they emerge gradually due to the continuous changes into the enviornment. New users are created but not included in existing policies New SaaS or enterprise apps bypass baseline controls MFA policies exist, but exclusions expand silently Legacy authentication or device code flow remains enabled for edge cases Multiple overlapping policies grow difficult to reason about Although there are tools like What‑If, Insights & Reporting, and Gap Analyzer workbooks help, they all require manual review and interpretation. At enterprise scale with large no of users and applications, this becomes increasingly reactive rather than preventative. What is the Conditional Access Optimization Agent? The Conditional Access Optimization Agent is one of the Microsoft Entra agents built to operate autonomously using Security Copilot. Its purpose is to continuously answer a critical question. Are all users, applications, and agent identities protected by the right Conditional Access policies - right now? The agent analyzes your tenant and recommends the following. Creating new policies Updating existing policies Consolidating similar policies Reviewing unexpected policy behavior patterns All recommendations are reviewable and optional, with actions typically staged in Report‑Only mode before enforcement. How the agents actually works ? The agent operates in two distinct phases - First the Analysis and then Recommendation & remediation During the analysis phase it evaluates the following. Enabled Conditional Access policies User, application, and agent identity coverage Authentication methods and device‑based controls Recent sign‑in activity (24‑hour evaluation window) Redundant or near‑duplicate policies This phase identifies gaps, overlaps, and deviations from Microsoft’s learned best practices. The next and final phase of recommendation and remediation depends on the results from the finding. Based on this the agent can suggest the following. Enforcing MFA where coverage is missing Adding device compliance or app protection requirements Blocking legacy authentication and device code flow Consolidating policies that differ only by minor conditions Creating new policies in report‑only mode Some of offer one click remediation making it easy for the administrators to control and enforce the decisions more appropriately. What are its key capabilities ? Continuous coverage validation The agent continuously checks for new users and applications that fall outside existing Conditional Access policy scope - one of the most common real‑world gaps in Zero Trust deployments. Policy consolidation support Large environments often accumulate near‑duplicate policies over time. The agent analyzes similar policy pairs and proposes consolidation, reducing policy sprawl while preserving intent. Plain‑language explanations Each recommendation includes a clear rationale explaining why the suggestion exists and what risk it addresses, helping administrators validate changes rather than blindly accepting automation. Policy review reports (This feature is still in preview) The agent can generate policy review reports that highlight spikes or dips in enforcement behavior—often early indicators of misconfiguration or unintended impact Beyond classic MFA and device controls, One of the most important use case is the agent also supports passkey adoption campaigns (This feature is still in preview) . It can include the following. Assess user readiness Generate phased deployment plans Guide enforcement once prerequisites are met This makes the agent not only a corrective tool, but it is helpful as a migration and modernization assistant for building phishing‑resistant authentication strategies. Zero Trust strategies utilizing agents For a mature Zero Trust strategies, the agent provides continuous assurance that Conditional Access intent does not drift as identities and applications evolve. The use of Conditional Access Optimization Agent does not replace the architectural design or automatic policy enforcement instead it can be utilized to ensure continuous evaluation, early‑alarm system for any policy drift and can act as a force‑multiplier for identity teams managing change at scale. The object of agent usage is to help close the gap upfront between policy intent depending on the actual use, instead of waiting for the analysis to complete upon resolving incidents and post auditing. In this modernized era, the identity environments are dynamic by default. The Microsoft Entra Conditional Access Optimization Agent reflects a shift toward continuous validation and assisted governance, where policies are no longer assumed to be correct simply because they exist. For organizations already mature in Conditional Access, the agent offers operational resilience. For those still building, it provides guardrails that scale with complexity but without removing human accountability.Sentinel to Defender Portal Migration - my 5 Gotchas to help you
The migration to the unified Defender portal is one of those transitions where the documentation covers "what's new" but glosses over what breaks on cutover day. Here are the gotchas that consistently catch teams off-guard, along with practical fixes. Gotcha 1: Automatic Connector Enablement When a Sentinel workspace connects to the Defender portal, Microsoft auto-enables certain connectors - often without clear notification. The most common surprises: Connector Auto-Enables? Impact Defender for Endpoint Yes EDR telemetry starts flowing, new alerts created Defender for Cloud Yes Additional incidents, potential ingestion cost increase Defender for Cloud Apps Conditional Depends on existing tenant config Azure AD Identity Protection No Stays in Sentinel workspace only Immediate action: Within 2 hours of connecting, navigate to Security.microsoft.com > Connectors & integrations > Data connectors and audit what auto-enabled. Compare against your pre-migration connector list and disable anything unplanned. Why this matters: Auto-enabled connectors can duplicate data sources - ingesting the same telemetry through both Sentinel and Defender connectors inflates Log Analytics costs by 20-40%. Gotcha 2: Incident Duplication The most disruptive surprise. The same incident appears twice: once from a Sentinel analytics rule, once from the Defender portal's auto-created incident creation rule. SOC teams get paged twice, deduplication breaks, and MTTR metrics go sideways. Diagnosis: SecurityIncident | where TimeGenerated > ago(7d) | summarize IncidentCount = count() by Title | where IncidentCount > 1 | order by IncidentCount desc If you see unexpected duplicates, the cause is almost certainly the auto-enabled Microsoft incident creation rule conflicting with your existing analytics rules. Fix: Disable the auto-created incident creation rule in Sentinel Automation rules, and rely on your existing analytics rule > incident mapping instead. This ensures incidents are created only through Sentinel's pipeline. Gotcha 3: Analytics Rule Title Dependencies The Defender portal matches incidents to analytics rules by title, not by rule ID. This creates subtle problems: Renaming a rule breaks the incident linkage Copying a rule with a similar title causes cross-linkage Two workspaces with identically named rules generate separate incidents for the same alert Prevention checklist: Audit all analytics rule titles for uniqueness before migration Document the title-to-GUID mapping as a reference Avoid renaming rules en masse during migration Use a naming convention like <Severity>_<Tactic>_<Technique> to prevent collisions Gotcha 4: RBAC Gaps Sentinel workspace RBAC roles don't directly translate to Defender portal permissions: Sentinel Role Defender Portal Equivalent Gap Microsoft Sentinel Responder Security Operator Minor - name change Microsoft Sentinel Contributor Security Operator + Security settings (manage) Significant - split across roles Sentinel Automation Contributor Automation Contributor (new) New role required Migration approach: Create new unified RBAC roles in the Defender portal that mirror your existing Sentinel permissions. Test with a pilot group before org-wide rollout. Keep workspace RBAC roles for 30 days as a fallback. Gotcha 5: Automation Rules Don't Auto-Migrate Sentinel automation rules and playbooks don't carry over to the Defender portal automatically. The syntax has changed, and not all Sentinel automation actions are available in Defender. Recommended approach: Export existing Sentinel automation rules (screenshot condition logic and actions) Recreate them in the Defender portal Run both in parallel for one week to validate behavior Retire Sentinel automation rules only after confirming Defender equivalents work correctly Practical Migration Timeline Phase 1 - Pre-migration (1-2 weeks before): Audit connectors, analytics rules, RBAC roles, and automation rules Document everything - titles, GUIDs, permissions, automation logic Test in a pilot environment first Phase 2 - Cutover day: Connect workspace to Defender portal Within 2 hours: audit auto-enabled connectors Within 4 hours: check for duplicate incidents Within 24 hours: validate RBAC and automation rules Phase 3 - Post-migration (1-2 weeks after): Monitor incident volume for duplication spikes Validate automation rules fire correctly Collect SOC team feedback on workflow impact After 1 week of stability: retire legacy automation rules Phase 4 - Cleanup (2-4 weeks after): Remove duplicate automation rules Archive workspace-specific RBAC roles once unified RBAC is stable Update SOC runbooks and documentation The bottom line: treat this as a parallel-run migration, not a lift-and-shift. Budget 2 weeks for parallel operations. Teams that rushed this transition consistently reported longer MTTR during the first month post-migration.
Recent Blogs
- 7 MIN READThe Challenge: Organizations deploying Microsoft Copilot and custom AI agents face a critical gap: security visibility is fragmented across data protection, identity governance, and threat detection...May 19, 2026
- Introduction To see why this problem scales so quickly, start with the smallest possible change: a single line of code. In modern software, even a tiny edit is rarely just a local modification. It...May 18, 2026
