The CISO Cheat Sheet to Microsoft Digital Defense Report 2026
I know we’re all busy, so I’ve pulled the most important data from this year’s Microsoft Digital Defense Report into one short read. The full report is well worth exploring, but this article focuses on the numbers and trends most relevant to security leaders. This year’s edition shows that AI is lowering the time, expertise and cost required to discover and exploit weaknesses, enabling attackers to operate with greater speed, scale and autonomy. The report describes this as AI “changing the physics of cybersecurity”: attack timelines are compressing and agentic systems are beginning to automate more of the attack lifecycle. Trend 1: Time has collapsed The clearest finding is about speed. Vulnerability discovery is increasingly running ahead of remediation, while the time from discovery to weaponisation is shrinking. In the AI era, weaponisation can follow in hours. Vulnerability discovery and weaponisation now often needs only a well-written prompt. The median time from discovery in the wild to weaponisation is below 24 hours. Vulnerabilities were on track for a record estimated 72,000 CVEs in 2026. The report expects a multi-year period in which the number of known but unpatched vulnerabilities rises sharply before eventually declining. The median time from container start to first exploit attempt is 5.3 hours. The ransomware actor Storm-1175 moved from web-facing exploitation to deploying Medusa ransomware in as little as 24 hours. CISA added over 110 CVEs to its Known Exploited Vulnerabilities catalogue between November 2025 and May 2026, most within a week of disclosure. The mismatch with enterprise reality is the uncomfortable part. The report says the disclosure-to-exploitation window has shrunk to single-digit days. Between November 2025 and May 2026, CISA added more than 110 vulnerabilities to its Known Exploited Vulnerabilities catalogue, most within a week of disclosure. In one example, Storm-1175 moved from exploiting a web-facing vulnerability to deploying Medusa ransomware in as little as 24 hours. Microsoft’s Red Team makes an important point: a patch is also a disclosure. Every fix points attackers towards the flaw it closes. As AI-assisted analysis makes reversing patches faster and more reliable, the report argues that patch velocity, not simply patch availability, becomes the control that matters. Trend 2: Attack chains are gaining autonomy The report charts a clear progression: September–November 2025: AI assists in orchestrating a campaign, as in the Anthropic-reported espionage case. April–June 2026: Full-chain autonomy is demonstrated in labs. July 2026: Real-world autonomous attacks of increasing complexity appear. Two frontier models, Mythos and GPT-5.5, completed a 32-step attack chain against an emulated enterprise with no human help. The test environment had no defenders. The UK AI Security Institute reached a similar finding independently. GPT-5.5 was the second model to solve its end-to-end corporate network attack simulation, a task AISI estimates would take a human about 20 hours. Open-weight models lag closed models at orchestrating attacks by about seven months. In the wild, early July 2026 saw the first documented automated ransomware extortion attack, named JADEPUFFER by Sysdig. Microsoft has seen AI-orchestrated intrusions that share elements with it. Initial access consistently came from internet-exposed services running known-vulnerable software. The report is measured on this point. Volumes of AI-orchestrated activity remain low. In most observed real-world operations, complex end-to-end intrusions still retain meaningful human direction. The Red Team's framing is the most useful one: AI doesn't create a new class of attack, it collapses the effort needed to find and exploit existing attack paths. Trend 3: AI has become an attack surface The report's second takeaway is that attackers are already targeting AI itself. The adoption numbers explain why. 88% of enterprises are experimenting with agents, and 82% of leaders plan broader rollouts within 12–18 months. The report cites industry projections of roughly 1.3 billion agents in production by 2028. What attackers are doing to AI systems: Four techniques accounted for roughly 90% of observed attack activity in telemetry from Azure AI workloads: malicious link injection (52%), jailbreaks (16%), tool and agent abuse (12%), and identity and credential abuse (10%). Memory poisoning: An attacker who can place content anywhere an agent reads can often place it where the agent remembers. Email is the dominant pathway the Red Team has observed. Human-in-the-loop isn't a complete control: Red team testing saw approval prompts ignored, or bypassed by a policy stored in poisoned memory. Developer tools turned against their owners: The "s1ngularity" malware hijacked locally installed AI command-line tools to hunt for secrets. It leaked about 2,000 secrets and 20,000 files across 225 victims. AI browsers: In daily use at more than 40% of organisations in Microsoft's dataset, they were the initial infection vector in incidents involving 57 malware families in a May 2026 analysis. Chat histories as a target: Malicious AI-assistant extensions reached nearly 900,000 installs and more than 20,000 enterprise tenants, harvesting AI chat histories that often contain code, architecture and credentials. The identity implications are direct. Each agent needs its own identity, not one borrowed from an employee, and a named human sponsor. The report also treats revocation latency, the time to cut off a compromised agent, as a measured outcome. Trend 4: The front door is still identity AI changes the speed and personalisation of social engineering. It hasn't changed where attacks start. Initial access in Defender Experts data: User execution: 30% Valid accounts: 20% Malicious copy-and-paste: 13% Phishing: 11% Together, user execution and valid accounts account for over half of observed activity. In incident response engagements, phishing as an initial access vector jumped from 7% to 23% year on year. The standout numbers: ClickFix: Defender saw user-pasted malicious commands on more than 1.1 million unique devices between February and early May 2026, roughly an 8x increase. AiTM: URLs accounted for 45% of the identified phishing techniques in the report’s breakdown. Separately, the share of AiTM phishing and token-theft attacks more than doubled during the first six months of 2026, although the report notes that their overall share remained comparatively small. Teams vishing: Weekly confirmed malicious volume increased 502% year on year. Per attempt, 48% of vishing calls kept the victim engaged for more than 20 seconds, and 30% lasted more than one minute. When a call succeeds, attackers can persuade the victim to install a remote-management tool and complete reconnaissance in two minutes or less. Business contact impersonation (BCI): The report introduces this term for conversations that start with a trusted-looking contact. Microsoft detected more than 46 million attacks in 12 months, with a 121% spike in April 2026. The share of first-contact messages that explicitly asked for money or documents fell from 17% to 3%. The first message is deliberately bland, like "Are you at your desk?" Password attacks declined 26% year on year, which the report describes as strong evidence that MFA and passkeys are forcing attackers to pivot. That pivot includes techniques such as fatigue attacks, AiTM phishing and token theft designed to circumvent conventional MFA. Trend 5: Attackers are inheriting trust rather than breaking in The report's headline theme is that risk is increasingly interconnected. Threats travel through the trusted relationships between identities, software supply chains, partners and cloud platforms. The numbers: Supply chain: Major open-source ecosystems saw attacks roughly every ten days, accelerating through Q2 2026. Shai-Hulud 2.0 affected 25,000 repositories. Megalodon backdoored 5,561 GitHub repositories in under six hours. Trusted signing: In May 2026, Microsoft disrupted Fox Tempest, a "malware-signing-as-a-service" operation that obtained genuine certificates for ransomware loaders and infostealers. Microsoft revoked over a thousand fraudulent code-signing certificates. Legitimate access: An unsanctioned remote monitoring tool is now one of the most reliable mid-stage indicators of a human-operated intrusion. Cloud identity: Cloud identity abuse was the most observed technique against critical infrastructure, representing 78% of the technique mix in Microsoft’s data for March to June 2026. Hybrid intrusions: The Storm-2885 case showed an attacker using a privileged cloud identity to close and downgrade security alerts. The report says identity governance and alert-handling workflows deserve Tier 0 treatment. Dwell time: DART data shows a statistically significant increase in dwell time year on year, meaning organisations took longer to detect intrusions. Ransomware shows the same ecosystem pattern. Qilin led leak-site data with 16.4% of victims, up 386%. Defender detections tell a different story, with Akira at 22%. Trend 6: Defence works best when it's connected The report is not only a catalogue of threats. The strongest defensive evidence: Disruption works. Following the March 2026 disruption, Tycoon2FA activity had fallen 95% from its November 2025 peak by June. Its share of CAPTCHA-gated phishing declined from 76% in December 2025 to 12% in June 2026. Correlation is the highest-leverage variable. The report argues that how well defenders share and correlate signals across endpoint, identity, cloud, email and network is one of the highest-leverage strategic variables under their control. AI is also changing defensive operations. The report describes AI-assisted triage, incident summarisation, hunting-query generation and detection engineering as ways to accelerate investigations and allow analysts to concentrate on higher-value work. Automated disruption can compress response time. The report says that when a correlated incident reaches a defined confidence threshold, defensive systems can automatically isolate devices, disable compromised accounts, revoke sessions or quarantine affected cloud resources. It also stresses the importance of appropriate governance and human oversight for high-risk AI actions. The report also recommends changing what leaders measure. It suggests moving from patches deployed to exposure reduced, detection coverage increased and time-to-mitigate compressed. What the MDDR recommends: ten security priorities The report starts its recommendations with the foundations: Secure by Design, Secure by Default and Secure Operations, applied through identity-centric Zero Trust. Microsoft says these keep the priorities below durable as AI adds more identities, applications, agents and dependencies to govern. Govern cyber risk at leadership level. Report identity exposure, patch latency, agent permissions, critical dependencies, dwell time and recovery readiness to the board. Defend identity as the primary control plane. Deploy passkeys and phishing-resistant MFA, reduce privilege and govern human and non-human identities. Invalidate and rotate tokens and session credentials quickly. Establish governance, visibility and data controls for AI. Keep visibility of approved AI tools, services and agents, and monitor for unauthorised or unmanaged use. Apply sensitivity-aware access and data protection to the data those systems can reach. Reduce exposure and edge risk. Continuously discover internet-facing assets and patch edge devices quickly. Centralise high-fidelity logging, enforce strong authentication and combine network visibility with threat intelligence. Focus on cross-signal correlation. Correlate endpoint, identity, cloud, application, email and network signals to detect intrusions earlier. Correlation also helps defenders anticipate attack paths and likely targets. Enact a continuous threat and vulnerability management model. Combine asset visibility, vulnerability identification, threat detection and AI-accelerated insight into a single continuous programme. Validate exposure through proactive testing. Run assume-breach exercises on cloud services, SaaS platforms, APIs and workflow automation. Prioritise them by where your highest-value data is stored, accessed or aggregated. Secure software dependencies. Harden software installation, keep a software inventory and validate provenance. Monitor packages and prepare for rapid containment. Participate in collective defence. Share actionable threat indicators and victim-informed intelligence with trusted partners and law enforcement. This supports coordinated tracking, investigation and disruption. Prepare for long-horizon technology transitions. Build a cryptographic inventory and advance post-quantum planning alongside AI governance. Read together, the numbers tell one story: the attacker’s workflow is becoming faster and less expensive. AI can shorten vulnerability discovery, exploitation, secret discovery and lateral movement, while organisations still face the slower operational work of testing, coordinating and deploying safe changes across complex environments. At the same time, agent identities can proliferate faster than organisations can inventory, govern and revoke them The defining question for boards today is not whether disruption will occur, but whether the organization can continue operating, contain harm, recover quickly, and maintain trust when it does. Source: Microsoft Digital Defense Report 2026, Version 1.1. Reporting period: July 2025–June 2026.
Unexpected Private Access rule after rebuilding Global Secure Access v2
Hello everyone, I'm rebuilding a Microsoft Entra Global Secure Access / Private Access POC after initially creating several configurations while learning the platform. I performed a clean functional rebuild: removed the previous application segments and assignments, reinstalled the Private Network Connector, created a new connector group, rebuilt Quick Access, and created a new custom Private Access traffic forwarding profile assigned only to my test account. My intended Quick Access configuration currently contains only three TCP destinations on the same private server: ports 80, 445 and 9000. However, the effective forwarding profile received by the Global Secure Access Client also contains an unexpected rule: 192.168.1.208 | All protocols | 54-65535 | Tunnel This rule existed in the original default Private Access profile and continues to appear even in a newly created custom profile. There is another unusual behavior in Acquisition Rules. An internal GUID reference is displayed in the profile, but the application selector shows Selected (0). The GUID cannot be removed through the UI, is not visible as a normal Enterprise Application, and I could not resolve it as either an Application or Service Principal through Microsoft Graph. I also found: ZTNA Network Access Client -- Private, which previously contained segments and assignments that I have since removed; two different objects named Carbomix - Rede Interna, with different identifiers; an error when attempting to remove an inherited link from the system-created profile: Only Profiles with IsCustomProfile set to true can be updated with bulk policy links. The connector itself appears healthy. I completely reinstalled it and the official Connector Diagnostics Tool passes certificate, TLS, CRL, Bootstrap, Trust Renewal, Service Bus, SLB and endpoint connectivity checks. Private Access also works for normal TCP traffic. TCP 445 and 9000 are successfully tunneled, including a sustained TCP session on port 9000. I'm mainly trying to understand: Where does the unexpected All protocols / 54-65535 rule come from? Why does it survive a clean custom Private Access profile? What are these internal application references that appear in Acquisition Rules but are not selectable/removable or resolvable through Graph? Could this be configuration inherited during migration to Traffic Forwarding Profiles v2? Is there a supported way to inspect and clean this inherited state? Has anyone working with Microsoft Entra Private Access v2 seen similar behavior? I have screenshots, effective forwarding-profile data, Connector Diagnostics results and Graph tests available and can share the relevant details as needed. Thanks!
When Authorization Changes Before Execution, Who Is Responsible for Validating Authority?
When Authorization Changes Before Execution, Who Is Responsible for Validating Authority? I've been exploring an architectural security question at the intersection of Microsoft Entra Workload Identity, Conditional Access, and Zero Trust. The question is: Can an identity remain successfully authenticated and authorized while the authority to perform a specific action becomes invalid because the execution context has changed? Consider a practical scenario: A workload identity is successfully authenticated. Authorization is granted for a particular operation. Before the operation executes, the surrounding conditions change. The application proceeds toward execution using previously established authorization. At that point, who is responsible for validating that the action is still authorized under the current execution context? Is that responsibility primarily held by: Identity layer: Establishing and maintaining the identity and its credentials? Policy enforcement layer: Evaluating changing conditions and authorization policies? Application layer: Validating authority immediately before executing an operation? Shared responsibility: Coordinating enforcement across all three layers? I'm not suggesting that Microsoft Entra currently fails to address this scenario, nor am I assuming that one layer should own the entire problem. I'm interested in understanding how the Microsoft community approaches the architectural boundary between: Workload identity lifecycle Delegated authorization Continuous evaluation of context Runtime policy enforcement Execution-time action validation This question becomes particularly interesting as organizations introduce autonomous AI agents and increasingly delegate operations to workloads that can act across multiple services. My question to the community: After authentication succeeds and authorization is granted, where should responsibility for validating continued authority reside when the execution context changes before an action occurs? Is this fundamentally an identity problem, a policy-enforcement problem, an application responsibility, or a combination of all three? I'd particularly welcome perspectives from Microsoft Entra engineers, identity architects, Conditional Access practitioners, and developers working with workload identities and AI agents. I'm interested in both practical implementation experiences and broader architectural principles. Thanks for sharing your perspectives. Kris Park Master Combine | Sovereign Engine Assurance GroupMicrosoft Entra provisioning Agent Error
Hello, I have deployed the Microsoft Entra provisioning agent in my organization, with synchronization configured from AD to Microsoft Entra ID. I am encountering an issue on the server where the Cloud Sync agent is installed: when connecting to Microsoft endpoints via a Squid proxy, I receive the error shown in the screenshot. The synchronization itself works perfectly, and the configuration status in the cloud is "Healthy." I frequently see the error shown in the screenshot (error code 12015), and I also occasionally encounter error code 12011. Has anyone experienced a similar issue? Could you please advise on how to resolve it? Thanks.
Jira SSO Logout Loop and UI Issues Across Plugin Versions
Hello Microsoft Entra Community, We are experiencing issues with the Microsoft Entra ID Single Sign-On integration in our Jira Service Management Data Center environment and would appreciate technical guidance. 1. ENVIRONMENT DETAILS Application: Jira Service Management Data Center Jira/JSM Version: 10.3.26 Identity Provider: Microsoft Entra ID PLUGIN VERSIONS AND ISSUES Version 1.1.11: We are experiencing an infinite SSO authentication redirect loop when customers log out of the JSM portal while Force Azure Login is enabled. Version 1.3.7: We are experiencing UI functionality issues after upgrading the plugin. Version 2.0.7: The logout/authentication redirect issue is also occurring in this version. CURRENT CONFIGURATION Force Azure Login: Enabled Enable Single Signout: Enabled 2. ISSUE DESCRIPTION When a customer logs in to the JSM portal using Microsoft Entra ID SSO and clicks Logout, Jira successfully terminates the local session. However, the Microsoft SSO plugin immediately redirects the user to Microsoft Entra ID. Since the Microsoft session is still active, the user is silently authenticated again. The plugin reports successful authentication, but Jira considers the user unauthenticated on the subsequent request. This results in a continuous redirect loop between Jira and Microsoft Entra ID. 3. FINDINGS FROM ATLASSIAN SUPPORT We raised a support request with Atlassian. Their technical investigation confirmed the following: Jira successfully terminates the user session during portal logout. Force Azure Login triggers a new authentication request immediately after logout. Microsoft Entra ID silently authenticates the existing Microsoft session. The plugin logs successful authentication. Jira does not retain the authenticated session on the next request. The /plugins/servlet/saml/logout endpoint is not invoked during JSM portal logout. Atlassian observed six authentication redirect cycles within approximately 15 seconds. Their conclusion was that Jira logout is working as expected and the issue appears to be occurring within the Microsoft Entra ID SSO plugin's authentication flow. TROUBLESHOOTING PERFORMED We temporarily disabled Force Azure Login while keeping Single Signout enabled. After this change, the logout redirect loop stopped, and the browser remained on the JSM portal login page. However, our requirement is to retain both Force Azure Login and Single Signout. 4. ASSISTANCE REQUIRED Are there any known defects in plugin versions 1.1.11, 1.3.7 or 2.0.7? Why does the plugin report successful authentication while Jira does not retain the authenticated session? Why is the SAML logout endpoint not invoked during JSM customer portal logout? What is causing the UI functionality issues observed in version 1.3.7? Why does the logout/authentication issue persist in version 2.0.7? Which plugin version is officially recommended for Jira/JSM 10.3.26? Is there a recommended configuration or permanent workaround that allows us to retain both Force Azure Login and Single Signout? We would appreciate technical guidance from the Microsoft Entra engineering team or anyone who has encountered and resolved similar issues. Our objective is to maintain a stable SSO integration while retaining both required security settings. Thank you for your assistance.AMA: What’s new in Microsoft Entra: Ask the experts
Have questions about the latest Microsoft Entra announcements from Microsoft Ignite? Bring them directly to the experts in this live Ask Microsoft Anything (AMA) event. Ask about unified access, identity governance, resilience, agent security, or other identity and network access innovations announced at Ignite. Whether you want to understand how a new capability applies to your environment, where to start, or what to consider next, this is your opportunity to get practical guidance directly from the Microsoft Entra team. I'm in! How do I sign up? Select “Add to calendar” to save the date and “Attend” to save your spot, receive event reminders, and participate in the Q&A. If you can’t make the live event, don’t worry. You can post your questions in advance and catch up on the answers and insights later in the week. This AMA will be recorded and available on demand immediately after airing. Where can I post my questions? Scroll to the bottom of this page and select “Comment.” Learn more. Tune in to our deep dive series: Scale secure, adaptive access without policy sprawl Strengthen governance, privileged access, and resilience across every identity and tenant Secure identity and access for every agent, local or cloud
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?Secure identity and access for every agent, local or cloud
Learn how Microsoft Entra helps secure AI agent identities and access across local devices and the cloud as your organization’s agent estate grows. As AI agents move beyond cloud environments and onto employee devices, identity and security teams face a new set of questions: Which agents exist? What are they doing? What can they access? And how can you distinguish an agent’s actions from a user’s? In this session, we’ll show how Microsoft Entra, working with Microsoft Agent 365, can help you manage AI agents at scale, govern agent identities and lifecycles, and protect access to organizational resources. We’ll cover supported Microsoft and third-party agent scenarios across both local and cloud environments, including which identity and access controls apply to each. Join us live for a practical look at what securing the growing agent estate means for identity and security teams. Watch the other sessions in this series: Scale secure, adaptive access without policy sprawl Strengthen governance, privileged access, and resilience across every identity and tenant
