AI helps cyberattackers move faster across the attack chain: personalizing social engineering at scale, automating reconnaissance, analyzing leaked credentials, identifying privileged users, probing exposed systems, and adapting tactics in real time. Attacks that once depended on manual effort can now unfold with greater speed, scale, and autonomy.

Yet even as methods evolve, identity remains one of the most common entry points. Every account, admin, workload, application, non-human identity, and AI agent can become a path to sensitive data and critical systems if not properly secured. Attackers do not need to break every defense; they only need to compromise or misuse the right identity with the right access at the right moment.

When attacks are accelerated by AI, speed and accuracy in detection and response are critical. Identity security can no longer operate in silos. Even a minor delay between when a threat is detected and action is taken can be the difference between suspicious activity becoming a contained incident or a business-impacting breach. This shift is reshaping how organizations think about security. The imperative is becoming clear: identity and security teams need comprehensive visibility and integrated solutions that streamline how they prevent, detect, and respond to identity threats.

Securing the future of identity at the speed of AI

One of the biggest security challenges organizations face today is fragmentation, and identity security is no exception. IAM and SOC teams often work across separate tools, separate workflows, and separate operational models. But identity attacks don’t respect those organizational boundaries.

Modern identity attacks span infrastructure, access control, and detection. At Microsoft, we understand this, and we are continuing to expand how Microsoft Entra and Microsoft Defender work together to provide more unified identity security experiences.

Actionable intelligence, everywhere

At RSA earlier this year, we unveiled our unified identity risk score, a new way to turn broader attack-chain insight into real-time access decisions. This score analyzes and correlates relevant signals across related accounts, sessions, workloads, and applications to surface a single, comprehensive evaluation of an identity’s true risk level and enable more dynamic response directly within authentication flows as part of risk-based Conditional Access policies.

View of a risky user within Entra ID Protection with new identity risk score and attack timeline.

Identity admins also gain a stronger operational experience through the new Microsoft Entra ID Protection experience. Rather than forcing identity teams to piece together risk signals across disconnected views, the updated experience brings deeper visibility into risky users, sign-ins, workloads, and associated detections in one place. The new identity risk score adds another layer of context by surfacing insights across related accounts and activity, including signals from Microsoft environments and connected identity activity beyond them. This helps admins understand whether a risky user, agent, workload, or sign-in is an isolated event or part of a broader pattern spanning sessions, applications, and associated accounts.

New user dashboard in Entra ID Protection which provides deeper visibility for identity admins into risky users, sign-ins, and associated detections.

New risky user details view provides more information about a user’s risk and the attack timeline within Entra ID Protection.

That richer context gives identity teams a more complete view of how risk is developing across the identity estate. Admins can better understand how risk is calculated, which related accounts or workloads contributed to the score, what detections are driving concern, and why a given identity requires attention. By connecting Microsoft and cross-environment signals into a single evaluation, the risk score helps identity admins prioritize the identities that matter most, make more informed access decisions, and explain the rationale behind remediation actions with greater confidence.

For security operations teams, this new score helps prioritize and triage investigations faster by focusing analysts on the identities that pose the greatest risk. But knowing what to fix is only half the challenge. In many organizations, security operations teams lack the needed permissions to take action; instead, they can only wait for separate IAM workflows to resolve the issue. That delay creates friction during moments when response speed matters most. Some solutions address this by giving SOC teams, or the security application itself, broad standing permissions across the identity environment. That may solve the permissions issue, but it also expands the blast radius if the application or identity is misused or compromised.

Microsoft takes a different approach because our solution natively spans identity infrastructure, the identity control plane, and ITDR. Customers get streamlined workflows across the full identity security lifecycle, and with a new identity-focused RBAC role, coming soon in public preview, security operations teams can access the core identity response actions they need without broad administrative permissions. This allows organizations to preserve least privilege access while reducing operational friction between IAM and SOC teams. Combined with the native privileged identity management in Microsoft Entra, organizations can also create just-in-time access policies for these response roles, further reducing standing privilege while still enabling responders to elevate quickly during incidents and investigations.

Together, unified risk, the new Microsoft Entra ID Protection experience, and least-privilege response roles give identity and security teams the shared context and governed action paths they need to move from insight to response faster.

Shifting left with proactive prevention

Shifting identity protection left means addressing risk earlier, before it becomes an active threat or incident. By continuously strengthening posture and adapting access controls as conditions change, organizations can reduce exposure, improve resilience, and stay ahead of emerging risks.

The Conditional Access Optimization Agent continues to evolve to help organizations keep pace with a rapidly changing threat landscape. Instead of manually auditing policies or reacting after gaps are exposed, the agent continuously analyzes identity signals, usage patterns, and emerging threats to recommend the right policy changes at the right time. New recommendations, like the “Block risky user agent” policy, are designed to address emerging attack vectors such as agent-based abuse and automated access attempts. These optimizations give organizations a more adaptive way to enforce Zero Trust, where access decisions continuously adjust based on risk and context rather than relying on one-time configuration.

And as part of our continued effort to help customers close the loop and move beyond reactive responses, we are soon bringing more threat detections and insights from Defender that are automatically fed directly into the Conditional Access Optimization recommendations in Microsoft Entra. Administrators receive clear, explainable, and reviewable recommendations that outline why the change is important, who is impacted, and what action to take, empowering a more proactive and preventative approach to mitigating future attacks.

Accelerating response

In AI-accelerated attacks, response speed matters just as much as visibility. Manual investigation and response will always be necessary, but in today’s AI-accelerated threat landscape, defenders need automation that helps level the playing field. That’s why we were so excited to extend the Security Alert Triage Agent to identity scenarios and pair it with automatic attack disruption and new predictive shielding capabilities. Together, these capabilities create an end-to-end automation loop that helps defenders triage identity threats, disrupt active attacks, drive response, and continuously harden posture before the next incident.

At Microsoft Security, we are building toward that future by embedding this kind of adaptive, AI-driven enforcement directly into identity security. That means accelerating detection across the attack chain, speeding up investigation and response through AI, and ensuring every authentication and access decision reflects real-time risk. It also means bringing IAM and security operations closer together, so identity signals, policy enforcement, and incident response work as one continuous system rather than separate workflows.

The future of identity security

In the AI era, identity is not just a control point. It is the system that connects prevention, detection, and response into a single, adaptive defense system. And Microsoft is building and operating that system as both the identity provider and policy enforcement layer, with real-time risk signals that can immediately influence access decisions. The organizations that defend identity fastest will be the organizations that defend everything else better.

-Sandeep Deo and Yaron Paryanty

Additional resources

• Identity security is the new pressure point for modern cyberattacks | Microsoft Security Blog
• Redefining identity security for the modern enterprise | Microsoft Community Hub
• Securing the Invisible Workforce | Microsoft Community Hub
• Get comprehensive identity threat detection and response

Learn more about Microsoft Entra 

Prevent identity attacks, ensure least privilege access, unify access controls, and improve the experience for users with comprehensive identity and network access solutions across on-premises and clouds.

• Microsoft Entra News and Insights | Microsoft Security Blog
• Microsoft Entra blog | Tech Community
• Microsoft Entra documentation | Microsoft Learn
• Microsoft Entra discussions | Microsoft Community

The post AI is accelerating cyberattacks—here’s how to stay ahead appeared first on Microsoft Security Blog.

High-quality behavioral evaluations are essential for understanding whether AI systems behave as intended. But the evaluations that product teams need generally don’t already exist, are often slow to build, are hard to validate, and are quick to go stale. Product requirements change; policies evolve; tools and retrieval environments shift; and models improve until yesterday’s benchmark no longer measures the behavior that matters. The intended behaviors are shaped by the product’s actual context, policies, and tools, but the evaluations used to assess them often only weakly reflect those conditions.  

The gap is most visible in application-specific behavior. A support agent should issue refunds below a threshold, escalate likely fraud, and decline out-of-policy requests. A research assistant should synthesize internal and public information without relying on restricted findings. A change-control agent should produce useful plans while respecting approval boundaries. Generic evaluators such as helpfulness, relevance, groundedness, toxicity, and faithfulness can be useful signals, but they don’t test these product-specific behavioral boundaries directly. A system can score well on generic metrics while failing application-specific requirements 

ASSERT is built on the premise that a behavior specification should be a first-class input to evaluation—not just the background context. The framework systematizes the specification, converts it into an inspectable taxonomy, generates stratified test cases from the taxonomy, runs the test cases against the target, and scores each failure against the policy statement that produced it. In the next section, we’ll walk through how each of those steps works in practice. 

How ASSERT works 

The pipeline has four stages. First, ASSERT turns a broad behavior specification into an explicit concept specification, which is then converted into a granular, editable behavior taxonomy with suggested permissible and impermissible behaviors. Next, it generates stratified test cases over the dimensions the developer declares. Then, it runs those cases against the target system and records the full trace, including tool use and intermediate decisions. Finally, ASSERT scores each trace against the behavior taxonomy and associated policy stance for that case, producing labels, rationales, and failure patterns that developers can inspect and refine. 

In the systematization stage, ASSERT turns a broad idea like harmful financial advice, tool-use governance, or unsafe health guidance into something concrete enough to evaluate. Rather than treating the concept as a single label, it represents it as a structured set of patterns, definitions, edge cases, and operational distinctions. Following Agarwal et al. (2026), ASSERT grounds the concept in prior work, reconciles multiple practical definitions, and refines the result into an explicit concept specification. 

In the taxonomization stage, ASSERT converts that specification into a draft taxonomy of permissible and impermissible behaviors, together with the artifacts used to derive it. Developers and policy experts can review and revise both before the next stage runs. The user can input the behavior description, number of test set samples they want, and a systematizer model. The taxonomization step outputs an editable behavior taxonomy that can be validated by a policy expert.

In the test-set generation stage, ASSERT instantiates that taxonomy into executable cases. It can generate single-turn prompts or multi-turn scenarios, including benign interactions and adversarial probes. Developers specify the dimensions that matter for the application, such as task type, persona, tool availability, request class, or environment configuration. ASSERT then builds a stratified set of cases so that behavior is tested across the declared conditions rather than on a narrow slice of easy examples. 

In the inference stage, ASSERT runs those cases against the target. The target can be a model, an agent, or an application-level workflow. Through its instrumentation layer, ASSERT records not only the final text output but also the evidence needed to interpret the result later: tool calls, retrieved context, routing behavior, and intermediate actions. For agentic systems, those traces are often necessary to understand what actually happened. 

In the scoring stage, ASSERT evaluates each trace against the associated behavior or policy stance.  The scoring output is not only a pass or flagged label, but also includes a rationale, a policy citation, and the turn or action that justified the verdict. The policy citation refers to the specific taxonomy behavior or developer-provided policy decision that the judge used to support the verdict.  

Validation 

We conducted two internal validation studies for ASSERT. First, we conducted a coverage study to determine whether ASSERT produces better behavior-specific evaluations than a more direct generation approach starting from the same written intent. Then, we evaluated the LLM judges against human review.  

The coverage study spanned five behaviors: social scoring, sycophancy, task adherence, tool-use governance, and unsafe health guidance. We tested whether the generated probes surfaced meaningful signal across the target behavior surface rather than collapsing onto a narrow slice of it. Across these suites and three target models, ASSERT produced evaluation sets that were more useful on the properties teams typically need from an eval. Compared with a comparable in-house baseline, ASSERT covered roughly 1.2x as much of the intended behavior space, surfaced about 1.5x as many cases where the model did something worth inspecting, produced more than 4x stronger separation between stronger and weaker systems, and had about half as many saturated cases where every model behaved the same way. It also surfaced roughly 2x as many distinct failure patterns, though we treat that result as directional because failure-type labeling is harder to stabilize than coverage or model separation. These results reinforced a design point that’s easy to underestimate: Coverage is largely determined upstream. If the behavior is underspecified, the generated dataset will be, too. ASSERT is built around a systematization step that makes the behavior explicit before generation begins, so the evaluation set is guided by a structured representation of the target behavior rather than a loose prompt. In practice, this produced evaluation sets that were broader and better aligned with the behaviors developers actually wanted to test. 

Second, we validated the judges directly against human review. Across more than 10 behavior concepts, we used LLM judges for a first pass over the full evaluation set, then sampled cases per risk for human validation and independent review. In practice, agreement between LLM judges and human annotators was typically in the 80–90% range, while human inter-annotator agreement was around 90%. This gave us confidence that the judges were capturing much of the intended signal, while also making clear where caution was needed. At the same time, judge quality and stability are partly dependent on the underlying LLM: Different judge models can vary in strictness, boundary sensitivity, and willingness to treat closely related behaviors as distinct. 

Finally, we also ran qualitative review with subject-matter experts (SMEs) on 15 generated datasets. SMEs reviewed the test cases for policy alignment, behavioral relevance, and overall quality and found that the generated datasets were generally well aligned with the intended policy and risk boundaries. We view this as a complementary form of validation: Beyond quantitative metrics, it showed that the datasets were also credible and useful to experts inspecting them directly. 

Taken together, these studies support the two claims we think matter most: Systematization improves the coverage and usefulness of the generated dataset, and decomposed measurements make the resulting evaluations easier to interpret than a single aggregate score. They also highlight an important caveat: Evaluation quality depends not only on the pipeline design, but also on the stability and calibration of the judges used to score it.

>“My favorite thing about ASSERT is that the eval is easy to configure and reason about. I describe the behavior I care about in YAML, point it at a real agent, and get artifacts back. Not just pass/fail. They show why the judge made each call. That openness matters. The spec, generated cases, model outputs, judge rationale, and metrics are all inspectable locally. The eval feels auditable, not like a black box.”

– Lorenze Jay, Open Source Lead, CrewAI

A worked example: A travel-planning agent 

To make this concrete, imagine a travel-planning agent that helps users build itineraries. On the surface, this sounds like a simple assistant: Find flights, suggest hotels, check the weather, and produce a plan. 

But a real travel agent has to do much more than answer a question. It must use tools in the right order, respect explicit user constraints, ground its recommendations in tool results, and avoid subtle failure modes that traditional single-turn QA benchmarks miss. 

For example, the agent shouldn’t invent flight prices. It shouldn’t agree with an itinerary that exceeds the user’s budget. It shouldn’t make stereotyped assumptions about a traveler based on age, disability, family status, or travel style. And it shouldn’t follow malicious instructions hidden inside tool outputs or search results. 

The example in the ASSERT repository uses a multi-agent LangGraph travel planner with five tools: 

• search_flights
• search_hotels
• check_weather
• check_travel_advisories
• validate_budget

It operates in a six-turn budget, and every run records the full agent trace (tool calls, arguments, tool results, routing decisions, and intermediate state) alongside the final response. That trace evidence is what makes the judge able to cite the specific action responsible for each verdict, not just the final reply. That trace is important. It lets the evaluator judge not only whether the final answer was acceptable, but why the agent failed and which action caused the failure. 

The full example lives in: examples/travel_planner_langgraph/ 

The evaluation configuration defines six failure-mode categories across two themes: 

• Quality: wrong or skipped tool use; fabricated flight, hotel, or price details; budget constraint violations
• Safety: stereotyping; prompt injection from tool output; sycophantic agreement with unsafe or invalid itineraries

To run the evaluation: Copy

assert-eval run --config eval_config.yaml # To inspect the results Assert-eval results status \ --results-dir "$PWD/artifacts/results" \ travel-planner-langgraph-v1 \ demo-1

ASSERT produces a set of artifacts under the run directory: 

• taxonomy.json: the concept spec produced by systematization
• test_set.jsonl: the stratified prompts and multi-turn scenarios
• inference_set.jsonl: per-scenario traces with tool calls and intermediate state
• scores.jsonl: per-trace verdicts with rationale and policy citation
• metrics.json: the aggregate roll-up

Example results:

The dimensions are separated rather than rolled into a single number: The same five scenarios produce 40% over-refusal and 60% policy violation, and those aren’t the same failures. A team optimizing on the aggregate would miss that the agent is failing in both directions at once. The results can be further inspected in a UI widget as shown below:

Practical considerations 

In practice, this framework works best when the behavior definition is relatively narrow and the relevant constraints are clearly specified. Richer descriptions of tools, policies, and boundaries usually lead to more precise scenarios. It’s also worth treating aggregate scores cautiously. In many cases, the most useful output isn’t the summary metric but the collection of failures and traces that shows where the specification, the system, or the evaluation itself needs refinement. ASSERT doesn’t remove the need for judgment in evaluation design. Vague specifications still produce vague scenarios. Synthetic interactions can miss failures that only appear in production settings. And model-based judges can be unreliable, especially when the policy distinction is subtle or highly domain-specific. More broadly, a specification-driven evaluation shouldn’t be treated as a compliance certification or a substitute for human review, telemetry, or domain expertise. It’s better understood as a way to make evaluation faster, more explicit, and easier to iterate on. 

Get started 

ASSERT is open-source under the MIT license and available today. 

• Repository: https://github.com/responsibleai/ASSERT
• Project site: responsibleai.github.io/ASSERT
• Worked example: travel-planning agent

If you build evals and run them as part of your release process, we’d like to hear what works, what doesn’t, and what behaviors you think are hardest to specify. ASSERT is at its most useful when behavior specifications are written down and treated as first-class inputs to evaluation. We’re releasing it in that spirit.

Acknowledgements 

PM team: Mehrnoosh Sameki, Minsoo Thigpen, Chang Liu, Abby Palia, Hanna Kim 

Science: Riccardo Fogliato, Emily Sheng, Alex Dow, Meera Chander, Alex Chouldechova, Sharman Tan, Xiawei Wang, Ahmed Magooda, Mayank Gupta, Jean Garcia-Gathright, Chad Atalla, Dan Vann, Hanna Wallach, Hannah Washington, Meredith Rodden, Nadine Frey, Melissa Kirkwood, Nick Pangakis, Ali Azad, Ahmed Elghory Ghoneim, Shushan Arakleyan 

Eng team: Mohamed Elmergawi, Jake Present, Aaron Aspinwall, Yeming Tang 

Design: Sooyeon Hwang, Becky Haruyama 

Special thanks: Roni Burd, Mohammad A, Heba Elfardy, Sandeep Atluri, Sydney Lister, Ram Shankar Siva Kumar, Andrew Gully 

The post Turn specs into evals for any agent with ASSERT appeared first on Microsoft Security Blog.

Why security has become a strategic enabler for AI‑powered growth 

These customer stories highlight how security is no longer a supporting function—it’s a strategic enabler of growth, speed, and trust. As AI accelerates decision-making and reshapes how work gets done, leaders must modernize without increasing risk or slowing the business. The experiences of these forward-looking organizations reflect the realities many companies face: gaining consistent visibility across complex environments, moving faster while maintaining trust, meeting governance and compliance expectations that expand with AI adoption, and driving operational efficiency through automation. These examples will show how the right security foundation allows organizations to scale AI with confidence—turning protection into a competitive advantage, not a constraint.  

First, we’ll take a closer look at St. Luke’s University Health Network. 

How St. Luke’s is accelerating efficiency and threat response with AI 

St. Luke’s identified a critical gap in unified, real-time visibility across its security tools, limiting its ability to detect and stop threats early. The organization needed a way to see across their entire landscape and respond to threats as they emerge. To modernize and unify security operations, St. Luke’s turned to Microsoft Security Copilot to supercharge analyst productivity and help its Security Operations Center (SOC) teams operate at scale. 

By connecting Microsoft Defender and Microsoft Sentinel, St. Luke’s gains a single, AI-powered view across endpoints, identity, email, and cloud workloads—helping analysts move faster, correlate cyberthreats more effectively, and shift from reactive response to proactive, predictive defense. With AI embedded directly into daily workflows, teams can identify risks in real time, uncover gaps in visibility, and make more informed decisions with greater precision.

Streamlining workflows and automating protection

At the same time, Security Copilot agents are transforming how the SOC operates by automating time-consuming tasks like alert triage and vulnerability remediation. This reduces noise, accelerates investigations, and frees analysts to focus on real threats and strategic work. The result is a more efficient, collaborative, and resilient security operation built for today’s increasingly complex threat landscape. With Microsoft Security Copilot, St. Luke’s has:

• Unified visibility across Defender and Microsoft Sentinel eliminates silos and accelerates threat response.
• AI-powered insights help analysts detect, investigate, and act on cyberthreats in real time.
• Security Copilot agents automating routine tasks, with Security Triage Agent saving up to 200 analyst hours each month.
• Advanced phishing triage reduces false positives and improves decision confidence.
• Centralized workflows improve collaboration, reporting speed, and overall SOC efficiency.

St. Luke’s sees its investment in Security Copilot as the foundation for a self-improving security ecosystem. AI-powered security means the team stays ahead of both technological and business changes, ensuring that St. Luke’s remains resilient in the face of evolving threats. To learn more about how St. Luke’s is modernizing and unifying security operations with Microsoft Security Copilot, watch the customer video or read the full St. Luke’s customer story.

How ManpowerGroup is securing a global workforce with a unified platform 

ManpowerGroup is modernizing toward a unified, cloud-based security platform to protect a highly distributed workforce, addressing identity-centric risk and complex compliance requirements as AI becomes embedded in everyday work. Their experiences show how organizations can use Microsoft Security to secure the foundation of AI transformation, end to end. 

As ManpowerGroup scaled globally, its longstanding mix of security tools became more difficult to manage, driving complexity, inconsistent controls, and slower response as cyberthreats and regulatory demands increased. 

To reduce tool sprawl, ManpowerGroup deployed Microsoft 365 E5 for the real-time identity, endpoint, email, and cloud prevention, detection, and response capabilities of Microsoft Defender, plus the cloud-native security information and event management (SIEM) and security orchestration, automation, and response (SOAR) performance of Microsoft Sentinel. 

By deploying Microsoft 365 E5, ManpowerGroup reduced security complexity, cut integration timelines from weeks or months to hours or days, unified global security operations, and built an AI-ready security foundation. To see how this platform approach is supporting secure, agile operations worldwide, watch the customer video read the full ManpowerGroup story. 

A repeatable playbook for securing AI at scale 

While these customers operate in very different environments, their paths to securing their organization and adopting (or preparing to adopt) AI followed the same core pattern—one that other organizations can adopt as they modernize. Both started by anchoring security decisions in business risk, then unified signals across cloud, data, identity, and operations, and finally automated guardrails so protection could scale alongside AI-powered work. These experiences point to a clear, repeatable approach for security and adopting AI without slowing business: 

• Lead with risk and business value. Clearly define what must be protected—and why—so security enables AI adoption rather than constraining it. 
• Unify visibility across the environment. Connect cloud, identity, data, and security operations (SecOps) signals into a single operational view to reduce blind spots. 
• Make governance real, not aspirational. Operationalize classification, labeling, data loss prevention, and policy enforcement, so protections are consistent by default. 
• Harden posture continuously. Use continuous configuration management and drift detection to prevent misconfigurations as environments evolve. 
• Automate outcomes at scale. Streamline response and compliance reporting so security and governance improve without increasing headcount. 

This approach helped both organizations move faster with confidence—and offers a practical blueprint for others looking to secure the foundation of AI transformation. 

What Frontier firms get right in the AI era 

These stories point to a broader pattern emerging among leading organizations. “Frontier firms” refers to organizations that lead in the AI era by pairing speed with trust. They move quickly—but not recklessly—because security is treated as a foundational capability, not an afterthought. For these organizations, protection is built into how work gets done: governance that scales as AI adoption grows, posture that remains resilient as environments change, and controls that operate continuously in the background. Security becomes the primitive that allows AI to be deployed with confidence, not constraint. 

These customers exemplify what this looks like in practice. And through their stories, we gain a playbook that other organizations can deploy with confidence. By modernizing security as a platform—connecting visibility, governance, posture management, and automation—organizations can enable AI-powered work while strengthening trust across data, identities, cloud environments, and more. These customer stories show that in the AI era, organizations that treat security as a strategic foundation will be best positioned to lead, adapt, and compete in an AI-powered world. Learn more about how Microsoft Security helps organizations secure AI-powered work at scale. 

Are you a regular user of Microsoft Defender for Cloud? Share your insights and experiences on Gartner Peer Insights.™

Learn more

Learn more about Microsoft Defender for Cloud, Microsoft Purview, and Zero Trust.

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.  

¹Secure agentic AI for your Frontier Transformation, Microsoft Security blog. March 9, 2026.

The post Microsoft Security success stories: How St. Luke’s and ManpowerGroup are securing AI foundations appeared first on Microsoft Security Blog.

There are more than 500 million monthly active players¹ across Xbox consoles, PC, handheld, and more through Xbox cloud gaming. They’re the folks who come to mind when people refer to “gaming culture.” But they’re not really the whole story. Globally, more than 3 billion people engage with gaming.² The majority of these people are gamers, but the number also includes developers working for independent gaming studios, engineers supporting the Xbox platform, and the security and operations professionals that support them all.

In my role as Deputy CISO for Gaming at Microsoft, it’s this much larger, much more complex community that I have to take into account. My team and I aren’t tasked solely with protecting consoles or player accounts. We’re safeguarding intellectual property (IP), live operations, and the trust of billions of interactions. We’re also partnering on risks that range from cheating and monetization exploits to supply chain vulnerabilities and regulatory compliance for child safety and privacy.

Gaming isn’t really a single culture, but rather a culture of cultures—each with their own risk factors to account for. At the heart of gaming is the player experience—their need for seamless access, low latency, and frictionless, immersive experiences. This goes hand-in-hand with privacy and safety in a world where cyberattackers could target well-known players. But aside from those basic needs, players form their own tribes, and a diverse, global player base requires a different approach—which makes securing gaming unique. You don’t approach it like you might traditional enterprise. Studios operate with creative autonomy, platforms demand global scale and low latency, and players expect frictionless experiences. That diversity makes gaming vibrant while also creating unique security challenges.

Each culture comes with its own security risks

Let’s first take a look at the risks that most often appear with each of the overlapping cultures that make up the world of gaming:

Platforms, underpinning services like Xbox Game Pass and Xbox Cloud Gaming, require centralized infrastructure with high availability. Here, security must integrate seamlessly with identity systems and Microsoft-wide standards without slowing down gameplay. But platforms face a number of distinct risks.

The complexity of platforms makes them a rich target for financially-motivated cyberattackers seeking to take over top accounts—or send targeted messages to individuals in an environment where they aren’t expecting phishing, which can threaten both ecosystem trust and commercial strategy. And because platforms serve as the connective tissue between devices, we have to pay special attention to weaknesses in integration points.

We also contend with fraud and abuse in commerce systems, where bad actors attempt to manipulate in-game economies or exploit payment flows. These persistent cyberthreats require layered defenses, real-time monitoring, and rapid responses.

Game development studios, whether they are AAA giants, indie teams, or sole developers, thrive on flexibility. Their environments are highly individualized and frequently blend proprietary tools with third-party assets and co-development with partners. My job is to make sure they can innovate securely—balancing their creative freedom with governance and compliance timelines. But this flexibility introduces risks that look very different from experienced by centralized platforms.

On the plus side, studios’ independence creates smaller failure domains, leaving them free to make their own choices and experiment with new tools, partners and engineering practices, without putting the broader platform and peer studios at risk. But reputation, regulatory liability, and cyberattacker interest can’t be firewalled off so easily. So, we need to establish a baseline of controls and detect anomalies early, closing down blind spots—despite fragmented development environments and third-party risk from studios that rely on external contractors, middleware providers, and asset marketplaces.

And some of the cyberattacks are the same: Without tight identity governance, credential sprawl can create highly-privileged accounts that become prime targets for threat actors. Studios operate under tight deadlines and with small margins, so we need empathy for their desire to make things easier—and to avoid security checks when under milestone pressure—despite the risk those actions could cause to production.

It’s also important to note that the driving factor for many threat actors targeting studios is the incredibly high value of unreleased IP. For the same reason, social engineering and insider threats are a constant risk for studios.

Studio Central Teams provide shared IT and infrastructure support. They’re the bridge between creative teams and operational security, ensuring that artists, producers, and marketers work in environments that are both productive and resilient. But that role comes with its own set of risks, which are often hidden in the complexity of shared services.

When central teams support diverse projects, maintaining consistent security baselines across cloud resources, build servers, and collaboration tools becomes difficult. Failing to maintain security consistency can lead to configuration drift—where a single misconfigured storage bucket or firewall rule can expose critical assets. But because central teams manage shared infrastructure, they are risk-averse to changes, including some critical security patches, that could cause cascading production failures.

These central teams can be security’s best partners for implementing strong monitoring and segmentation—but also need to be governed to avoid insider risk and toxic combinations of overlapping permissions.

Collaboration over control

Security in gaming isn’t about imposing rules. It’s more about partnership. I work closely with Temi Adabambo, General Manager for Gaming Security, Microsoft, and Eric Mourinho, Chief Architect, Microsoft, to co-develop secure environments and shared tooling. Governance is a dialogue. We collaborate between platform teams, studio IT, security architects, and technical directors in game studios. That’s how we manage exception handling, cross-team dependencies, and the tension between creative speed and security rigor.

One of the advantages of the Microsoft environment is the access it grants us to a security ecosystem that scales globally. In gaming, we build upon that foundation, adapting it for the unique needs of developers, platforms, and players:

• Identity and access management: We use Microsoft Entra ID to secure identities across Xbox Live, Game Pass, and studio environments. Shared identity systems allow frictionless sign-in for players while enforcing strong authentication for developers and partners.
• Compliance and governance: We rely on a combination of tools and processes to manage sensitive data and meet regulatory obligations across environments like public cloud infrastructure and bespoke studio setups. This includes Microsoft Purview for data classification and compliance monitoring, Microsoft Defender for Cloud for policy enforcement and resource hardening, Entra ID for identity governance, and Microsoft Sentinel for audit and reporting. Together, these capabilities help us maintain visibility, enforce standards, and respond quickly to compliance exceptions without slowing down development.
• Threat intelligence and detection: With Microsoft Defender for Cloud, Microsoft Sentinel, and proprietary Microsoft tooling, we gain visibility into cyberthreats across platforms and supply chains. These tools allow us to detect anomalies, respond quickly, and share intelligence across teams without slowing down creative workflows.
• Secure development lifecycles: We embed security into game development through automated code scanning, vulnerability management, and secure build pipelines, helping studios ship faster without sacrificing safety.

These are enterprise-grade capabilities, adapted to the needs of the global gaming culture of cultures. They allow us to protect billions of interactions while enabling the creativity that defines this industry. 

Looking ahead 

Gaming will only grow more complex. But I see that as an opportunity. Security presents challenges, but in facing those challenges head-on, we are constantly refining our practices, products, and player experiences. When we design for resilience, we protect not just games but the communities that help them thrive.

For Microsoft, that means treating gaming security as an ever-evolving system—one that changes with each new iteration of technology, player expectations, and the creative heartbeat of the industry.

Security teams and their families are gamers too. Visit the Xbox Wire and our recent blog post for Safer Internet Day to learn more about how we keep players and communities safe and secure at Xbox.

Microsoft
Deputy CISOs

To hear more from Microsoft Deputy CISOs, check out the OCISO blog series:

To stay on top of important security industry updates, explore resources specifically designed for CISOs, and learn best practices for improving your organization’s security posture, join the Microsoft CISO Digest distribution list.

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

¹Microsoft FY25 Fourth Quarter Earnings Conference Call  

²Microsoft to acquire Activision Blizzard to bring the joy and community of gaming to everyone, across every device 

The post Securing the gaming culture of cultures appeared first on Microsoft Security Blog.

The key question is: How can we maximize the benefits of AI while staying protected in a rapidly evolving threat landscape?

Cybersecurity—from IT issue to business risk

Today’s cybersecurity landscape is defined by speed, scale, and automation—trends that disproportionately affect growing businesses. According to the 2025 Microsoft Digital Defense Report, Microsoft now processes more than 100 trillion security signals every day and blocks 4.5 million new malware files daily, underscoring just how industrialized cybercrime has become. Increasingly, cyberattackers are using AI to automate phishing, generate highly convincing scams, and rapidly adapt malware, making cyberattacks more frequent and harder to detect.

For businesses that often lack dedicated security teams or round-the-clock monitoring, this shift has real business consequences: disrupted operations, financial loss from ransomware or fraud, and lasting damage to customer trust. The report also notes that most modern cyberattacks now target identities, like user accounts and access—a challenge for organizations relying on cloud services and remote work without strong protections in place for accounts and access. As AI continues to amplify both the volume and sophistication of cyberattacks, cybersecurity is no longer just an IT issue for businesses—it’s a core business risk that can directly affect resilience and growth.

Building a foundation of trust

In this new reality, security becomes the foundation of trust—helping growing businesses protect their operations, preserve customer trust, and move forward with confidence. For business owners, cybersecurity isn’t just about stopping cyberattacks; it’s about keeping the business running day to day. When systems go down, orders can’t be processed, employees can’t do their work, and customers are left waiting or wondering whether their data is safe. Even short disruptions can have outsized consequences for growing businesses, from lost revenue and stalled growth to reputational damage that’s hard to repair. By making security a core part of how the business operates—not an afterthought—even the smallest businesses put themselves in a stronger position to withstand disruptions, maintain credibility with customers, and create a stable foundation for long-term growth.

Simple, built‑in security for your growing business

Effective security must be simple, approachable, and fit the realities of running a business with limited time and resources. Many growing businesses don’t have dedicated security teams or the time and resources to manage complex tools, yet they still need protection that keeps pace with modern threats. Microsoft Security is built with this in mind, offering integrated, easy‑to‑manage protections that help safeguard devices, identities, email, and cloud apps without adding unnecessary complexity. Microsoft 365 Business Premium combines productivity and built-in security in one streamlined solution, with centralized visibility and automation that reduces manual effort. It helps protect your users, devices, and data across your business, so you can stay focused on customers and day-to-day operations. By providing security that works quietly in the background—and scales as the business grows—Microsoft helps businesses of all sizes protect what matters most without slowing them down.

Allowing people to operate devices and applications without conditional access increases risks. Getting that done was a huge success for us.“

—Theo Mouchteros, Head of IT Operations, Acumen

Take the next step

To discover the right security plan for growing business, read our small and medium business plans and pricing options or contact Microsoft Sales for more support.

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

¹Microsoft Digital Defense Report 2025.

²Cyber Signals Issue 9.

³The Devastating Impact of Ransomware Attacks on Small Businesses.

The post How to better protect your growing business in an AI-powered world appeared first on Microsoft Security Blog.

DDoS activity across Bing and other online services at Microsoft has seen a large uptick in the past five to six years. As reported in the Microsoft Digital Defense Report 2025, Microsoft now processes more than 100 trillion security signals, blocks approximately 4.5 million new malware attempts, analyzes 38 million identity risk detections, and screens 5 billion emails for malicious content each day. This helps illustrate both the breadth of modern attack surfaces and the automation cyberattackers can now wield at industrial scale. When we narrow in specifically on DDoS, an even clearer trend emerges: beginning in mid-March of 2024, Microsoft observed a rise in network DDoS attacks that eventually reached approximately 4,500 cyberattacks per day by June 2024. And this persistent volume was paired with a shift toward more stealthy application-layer techniques.

In my role as Vice President, Intelligent Conversation and Communications Cloud Platform at Microsoft, I focus on helping the Microsoft AI and Bing teams build systems that are safe, resilient, and worthy of user trust, even under the sustained pressure we’re receiving from today’s cyberattackers. Whether you are responsible for a single public website or a large portfolio of consumer-facing applications, defending against modern DDoS attacks means more than just absorbing traffic. It means building defense-in-depth robust enough that, even if some attack traffic gets through, your service stays usable for the people who rely on it.

The nature of modern DDoS attacks

Early DDoS attacks were largely about volume. Cyberattackers would flood a target with traffic in an attempt to saturate network capacity and force an outage. While volumetric attacks still happen, most large services now have baseline protections that make this approach less effective on its own.

Modern DDoS attacks are more nuanced. They are often multi-vector, with a single campaign potentially including network-layer floods and application-layer abuse at the same time. Along with the exponential increase in the scale of these cyberattacks, they are also getting more tailored to stress specific applications and user flows. Application-layer attacks are gaining popularity because they are harder to distinguish from legitimate usage.

We also see threat actors utilizing a broader range of devices in botnets, including consumer Internet of Things (IoT) devices and misconfigured cloud workloads. In some cases, cyberattackers abuse legitimate cloud infrastructure to generate traffic that blends in with normal usage patterns. Edge systems, such as content delivery networks (CDNs) and front-door routing services, are increasingly targeted because they sit at the boundary between users and applications.

When attack traffic looks like normal user traffic, typical network-level blocklists aren’t very effective. You need sophisticated fingerprinting (starting with JA4), layered controls, and good operational visibility. This evolution is part of what makes defending against DDoS more than a networking problem. It is now a system design problem, an operational monitoring problem, and ultimately a trust problem.

A defense-in-depth framework

Even if you block 95% of malicious traffic, the remaining 5% can still be enough to take you down if it hits the right bottleneck. That’s why defense-in-depth matters.

A strong defensive posture starts with making abnormal traffic easier to spot and harder to exploit. Techniques like rate limiting, geo-fencing, and basic anomaly detection remain foundational. They are most effective when tuned to your specific traffic patterns. Cloud-native DDoS protection services play an important role here by absorbing large-scale attacks and surfacing telemetry that helps teams understand what is happening in real time. If you run on Azure, there are built-in options that can help when used as part of a broader design. Azure DDoS Protection is designed to mitigate network-layer cyberattacks and is intended to be used alongside application design best practices. At the edge, services like Azure Web Application Firewall (WAF) on Azure Front Door can provide centralized request inspection, managed rule sets, geo-filtering, and bot-related controls to reduce malicious traffic before it reaches your origins.

Microsoft publishes a range of Secure Future Initiative (SFI) guidance and engineering blogs that describe patterns we use internally to harden consumer services at scale, and if you’re looking to assess how robust your site’s current DDoS resilience posture is, here’s a simple tabular framework to work from:

Planning for graceful degradation

One of the most common misconceptions about DDoS defense is that success means “no reduction in services.” In reality, even a partially successful attack can degrade performance enough to frustrate users or erode trust, without triggering a full outage. Graceful degradation is about maintaining core functionality even when systems are under stress. It means being deliberate about which user flows must remain available and which can be temporarily limited without causing disproportionate harm.

For example, our systems prioritize core scenarios over secondary features during extremely large cyberattacks. In practice, this can mean temporarily delaying nonessential personalization or shedding load from less critical features to preserve overall responsiveness. These decisions are made in advance and tested, not improvised during an incident. Here’s an example of how we might do that:

• Prioritizing core user flows: We would focus on keeping core scenarios responsive. That might mean protecting one or two core scenarios while de-emphasizing secondary experiences.

• Reducing expensive work first: Some parts of an experience are computationally heavier. Under attack pressure, those are candidates for temporary reduction, so the overall service stays usable.

• Tiered experience under load: In extreme conditions, you can provide a better experience for users with higher trust signals while still offering an acceptable experience to everyone else. This is not about punishing lower trust users. It is about making sure your system can still serve legitimate demand when resources are constrained.

• Clear user messaging: If you need to disable or simplify a feature temporarily, communicate it in a way that is honest and calm. You do not need to explain your internal architecture. You do need to be predictable.

Designing for resilience means assuming that individual components will fail or be stressed at some point. Systems that are built with that expectation tend to recover faster and maintain user trust more effectively than systems that aim for perfect uptime at all costs.

Get started improving your DDoS defense

If I could leave you with a single practical concept, it would be this: treat DDoS as a normal operating condition for internet-facing services. Build defense in depth. Assume some cyberattack traffic will get through. Design your service so it can degrade gracefully while protecting the user experiences that matter most.

Consumer trust is fragile and hard-earned. Developers and operators who think beyond raw availability, and who design for transparency, prioritization, and resilience, are better positioned to handle the realities of today’s cyberthreat landscape. Modern defensive strategies combine proactive controls, thoughtful architecture, and a clear understanding of what matters most to users.

For those interested in going deeper, I encourage you to explore the Secure Future Initiative resources and the other Office of the CISO blogs provided by my peers at Microsoft. Both of these resources frequently share practical patterns for building and operating resilient services at scale.

Microsoft
Deputy CISOs

To hear more from Microsoft Deputy CISOs, check out the OCISO blog series:

To stay on top of important security industry updates, explore resources specifically designed for CISOs, and learn best practices for improving your organization’s security posture, join the Microsoft CISO Digest distribution list.

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.  

The post Defending consumer web properties against modern DDoS attacks appeared first on Microsoft Security Blog.

Passwords remain a major source of risk; they’re difficult to manage and easy to steal. Along with weaker forms of multifactor authentication, they’re also highly vulnerable to phishing: AI-powered campaigns drive click-through rates as high as 54%.¹ In response, Microsoft is expanding passkey adoption across our ecosystem. We’re reducing reliance on legacy authentication and strengthening account recovery so it won’t become a backdoor for cyberattackers.

Passkey adoption continues to grow industry wide

Passkey adoption is accelerating: FIDO Alliance estimates 5 billion passkeys already in use worldwide.² Across Microsoft’s consumer services, including OneDrive, Xbox, and Copilot, hundreds of millions of users sign in with passkeys every day.

There are many reasons to choose passkeys as the standard authentication method over passwords. Sign-in success rates are significantly higher than with passwords, and exposure to credential-based attacks is significantly lower.³ Organizations and individual users alike prefer the simpler, more secure sign-in experience passkeys offer.⁴

Inside Microsoft, we’ve eliminated weaker authentication methods and rolled out phishing-resistant authentication, covering 99.6% of users and devices in our environment.⁵ It’s made signing in a lot simpler: no codes to enter, no extra prompts to manage, just a straightforward experience for everyone.

Product updates across sign-in and recovery

Across Microsoft, we’ve been steadily building passkey support into every layer of the identity experience from consumer accounts to enterprise access with Microsoft Entra, and from device-based authentication like Windows Hello to Microsoft’s password manager. This work ensures people can create and use passkeys wherever they sign in, with a consistent, phishing-resistant experience across devices, apps, and environments.

To make passkeys more accessible, we’re expanding where and how people can use them:

• Synced passkeys and passkey profiles in Microsoft Entra ID make it easier to scale passwordless sign-in across diverse environments. We’re expanding flexibility in cloud passkey management, including support for larger and more complex policies, and transitioning tenants to a unified passkey profile model.
• Entra passkeys on Windows make it simple for users to create and use device-bound passkeys directly on personal or unmanaged Windows devices using Windows Hello, and will be generally available in late May 2026.
• Passkeys for Microsoft Entra External ID will be generally available late May 2026, so your customer-facing applications can offer a more seamless, consumer-grade sign-in experience.
• Passkey-preferred authentication in Microsoft Entra ID (preview) detects registered methods and prompts the strongest one first. If a passkey is registered, that’s what the user sees—immediately. 
• On the consumer side, with Microsoft Password Manager, users can now save and sync passkeys across devices signed in with their Microsoft account, with support for iOS and Android rolling out soon through Microsoft Edge. 

Account recovery also plays a critical role in maintaining the integrity of identity systems. Historically, it’s been vulnerable to cyberattackers who try to hijack the recovery process, for example by impersonating legitimate users and requesting new credentials.

Microsoft Entra ID account recovery, generally available today, strengthens security for recovery flows by enabling users to regain access to their accounts through a robust identity verification process. Users can regain access after losing all authentication methods by using government-issued ID and biometric face checks. At general availability, we are expanding our identity verification ecosystem with two new partners—1Kosmos and CLEAR1—joining our existing partners Au10tix, IDEMIA, and TrueCredential. 

Removing phishable credentials from user accounts

Strengthening authentication is important, but reducing risk means eliminating phishable credentials entirely. Microsoft is continuing to phase out legacy methods and move users toward phishing-resistant authentication. Starting in January 2027, security questions will be removed as a password reset option in Microsoft Entra ID due to their susceptibility to guessing and social engineering.

The rationale is straightforward: improving strong methods while removing weak ones shrinks the attack surface. This is increasingly urgent as AI agents act on behalf of users. If an identity is compromised, cyberattackers can leverage those agents to access systems, execute workflows, and operate within existing permissions. Organizations need to address this risk quickly.

A more secure and usable future

Last year, Microsoft joined dozens of organizations in taking the Passkey Pledge, a commitment to accelerating the adoption of phishing-resistant authentication and to moving beyond passwords. Since then, we’ve seen meaningful progress, from hundreds of millions of better-protected consumer accounts to large-scale deployments across organizations like our own.

What once felt like a long-term shift is finally gaining real momentum: authentication is becoming simpler, safer, and passwordless.

For a more in-depth perspective on how cyberattackers try to bypass authentication through fallback methods and recovery flows—and how to address those gaps—read our companion post.

Getting started

Organizations that want to strengthen their identity security posture can enable passkeys for their users and extend policy protections across both sign-in and recovery scenarios.

Get started with a phishing-resistant passwordless authentication deployment in Microsoft Entra ID.

Individuals can create and use passkeys for their personal accounts for better security and convenience.

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

¹Microsoft Digital Defense Report 2025.

²FIDO Alliance reports mainstream global usage on World Passkey Day. FIDO Alliance, 2026.

³Synced passkeys and high assurance account recovery, Microsoft Entra blog. December 16, 2025.

⁴FIDO Alliance Champions Widespread Passkey Adoption and a Passwordless Future on World Passkey Day 2025, FIDO News Center. May 1, 2025.

⁵Microsoft Security and Future Initiative (SFI) Progress Report—November 2025.

The post World Passkey Day: Advancing passwordless authentication appeared first on Microsoft Security Blog.

The nature of cyberthreats has never been static, but it’s hard to accurately convey the scale of their recent evolution and proliferation. As we’ve seen in many other arenas, AI has become a very powerful productivity tool for would-be cybercriminals. Between April 2024 and April 2025, Microsoft stopped $4 billion in fraud attempts.¹ And as of the writing of the Microsoft Digital Defense Report 2025, we are tracking 100 trillion security signals each day (a 40% increase since 2023).²

This is why I decided to write a blog about risk reviews. By asking the right questions, risk reviews help us transform the utility of our security data from primarily reactive remediation and response information into key insights helping to inform our proactive security stances. And embracing strong proactive security is something we can all do to mitigate our increased exposure to security threats.  

Risk reviews are also a topic I’ve lent focus to during my first six months as Deputy CISO for Microsoft Security. It’s a very interesting role for me, as I’ve traditionally described myself as performance specialist and a systems specialist more than a security specialist. It’s not necessarily a distinction of skill set, but more one of mindset, and what I’d like to share with you is actually a bit of a synthesis of my inherent performance- and systems-first way of thinking and things I’ve brought into that practice after working with many of the other Microsoft Deputy CISOs over the last few months.

There are roughly eight points I want to bring up concerning risk reviews in this blog. Each point has the potential to help expose potential security vulnerabilities when brought up with security teams. Together, they represent a structured and approachable way to initiate necessary conversations and drive meaningful results:

1. Assets
2. Applications 
3. Authentication 
4. Authorization 
5. Network isolation 
6. Detections 
7. Auditing 
8. Things not to miss 

Now, why did I choose to highlight these areas and not others? Generally, I find that looking at problems from the lens of risk management gives me a fresh perspective. When you very consistently ask specific questions around these areas, they often effectively start the conversation you want to have.

Just one last thing before we dive in: What I’m about to tell you is only approximately correct. There will be edge cases and exceptions, but generally I think you’ll find this information helpful.

1. Assets

The best place to start a review is identifying the assets that you need to protect. This will largely define the scope of the review. A good place to find those assets is, of course, on your architecture diagrams and your threat models. The assets we’re talking about could be storage (where perhaps you’re storing sensitive or otherwise important data) or they could be highly-privileged applications like command-and-control systems or something similar. This is, in short, the list of things that your cyberattacker wants to get to. 

2. Applications

In the next step, you identify your applications. These are, broadly speaking, the active part of your system. They are the outward-facing surfaces that customers will use and the set of microservices that support your interface. These systems could be providing any set of services that you might need—and herein lies the problem. It’s entirely normal for your applications to require access to your most important assets, but that means the applications themselves can become viable targets for a cyberattacker. So how do we make this situation better? At this point, it’s reasonable to start talking about possible controls. 

Read up on Zero Trust for source code access.

3. Good quality authentication 

The next thing you will want to inspect is the form of authentication that your system is using. The best systems are using tokens for authentication, and they are getting these tokens from standard token issuers like, for instance, Microsoft Entra. It’s sometimes viable to have your own token generation system, but remember that such systems tend to have bugs. Those bugs can be exploitable. And even lacking bugs, there could be, say, gaps or vulnerabilities in your token issuing system such that perhaps the tokens cannot be properly scoped. The tokens could also tend to be too long-lived, or difficult to be made fine-grained enough, or lack the capacity to allow for flowing user context from the request to the authorization system. Many such deficiencies are possible. 

Even with a good quality token issuing system, you can easily find yourself in a situation where the tokens that you’re creating are too fungible, or too powerful, or both. Thinking back to the assets you’re trying to protect and the applications that you have, you can likely categorize some of the applications as having more “power,” if you will, than others. Sometimes we call these “highly privileged applications” because they have the capability to do something that is especially of interest to cyberattackers, like reading a lot of data, changing configuration, or anything like that. 

To best manage the privileges associated with these applications, it needs to be the case that the kinds of tokens that they use are as limited as possible. So, a particular token might authorize a capability for a certain customer, on behalf of a certain user, for a certain set of data—and nothing more than that. When privileges are very generic, like “I can do this operation for anyone, anywhere,” things become much more dangerous. So, here the idea is to make sure that the tokens that you’re getting are very specific to the intent that you have and that only the applications that need those tokens can get them, and, again, the tokens are as limited as possible. This goes a long way in reducing the possible damage that a cyberattacker could do if they found such a token errantly stored somewhere. 

A lot of the things we think about when we’re working with tokens and trying to limit them fall into the category of limiting what a cyberattacker can do if they get a foothold somewhere. This is the Zero Trust model, where you assume breach everywhere.  

Additionally, it’s essential to use standard libraries to accurately authenticate with tokens, so that all the aspects and limitations of the token are certain to be honored. 

Learn about phishing-resistant multifactor authentication from the Microsoft Secure Future Initiative (SFI). 

4. Good quality authorization  

Good quality tokens are not going to help you if they’re enforced poorly (or not at all). And bugs can creep into code. Ad hoc authorization code can render the good authentication that you’ve done moot. 

Any time you can use declarative style patterns that help you verify tokens against incoming APIs and the data that the client is attempting to access with your API, you’ll find yourself in a better place. Simple, consistent authorization yields fewer bugs and therefore less risk. 

5. Network isolation 

In addition to having good quality tokens, it’s important to isolate the pieces of your environment to the maximum extent possible. Again, this is done because it’s prudent to assume that a cyberattacker has a foothold somewhere in your network. The questions are “where exactly can that foothold be,” and “once they have that foothold, where in my network can they get to?” If a threat actor can reach any part of your system from any other part of your system, this is obviously less good than if your most sensitive systems can be accessed from exactly one or two key places and nowhere else. When properly controlled, most footholds become useless to a cyberattacker—or at least only indirectly useful.  

Use service tags to create boundaries around your various assets such that applications are used by exactly those systems that are supposed to be using them and data is accessed by exactly those applications that are supposed to be accessing the data. This goes a long way to take many cyberthreats off the table.  

Network isolation can happen at several levels in the network stack. Popularly, level 7 is used at the perimeter. Maybe this manifests as some kind of HTTP proxy, for example, or an HTTP routing gateway. However, protection is incomplete without additional work happening at level 3 within your network. You want to limit IP traffic to be going to exactly the places that you want it to go. You might use techniques like virtual LANs, or similar constructs like network security groups (NSGs) in Microsoft Azure. The idea is to limit connectivity to exactly what is necessary to do the job and not give the cyberattacker freedom to move around. 

With good network isolation comes the ability to log any attempts to gain access at the perimeter, and potentially even internally. Depending on what networking technology you’re using, all of this is great for hunting. We’ll talk about that in the next section.  

Learn more about network isolation and other best practices from SFI.

6. Detections  

It’s normal to think about monitoring for reliability. Systems need to stay within their operating parameters in the face of changes and external conditions. But it’s also important to think about detection from the perspective of your threat model. If you identify five or ten risks in your threat model that need controls, it’s useful to think about how you might detect if any of those things are actually happening in your environment.  

In this context, one place to look is at the perimeter—by examining your incoming HTTP traffic, for instance. But you can also look anywhere in your environment where you predict that attacks might happen. You might look for badly formatted requests, or fuzzing, or evidence of DDoS attack—whatever is appropriate to the risks you have. The idea is that you want to be able to create alerts if you have evidence of a threat actor operating in your estate.  

And, of course, security products can be very helpful here.  

7. Auditing

We separate the notions of auditing from detection. Specifically, auditing is what I will call the pieces of data that you would use after a breach to determine the extent of the breach and the customers that were affected by it. In the event that you find a vulnerability without any evidence of threat actor exploitation, you’d want to go and check your auditing again to verify those claims. That way you can have evidence that whatever problem you found was not in fact exploited. If it was exploited, you’ll know to what extent, who was affected, and who needs to be notified. 

Some parts of your endpoint detection and response (EDR) stream will be very useful for auditing. Additional auditing information can come from the logs you create in your applications that record suitable information concerning recent activity. 

8. Things not to miss 

It’s important to think about all the applications and data that you have in your estate. For instance, it’s easy to overlook the backup data that you have stored. A cyberattacker might not be able to get access to your primary systems but might find that your backups are entirely unprotected and they can just read the backup.

Similarly, support systems often go overlooked. There are frequently important customer support scenarios that require access, and it’s easy to fall into the trap of not giving those systems the highest level of scrutiny. 

We should add systems that are under development and test systems to this problematic set. In both these cases, the code that’s running those systems is less trustworthy than normal production code. Development code, for instance, can be presumed to have more bugs than production code. Some of those bugs might be authorization bugs. And if there are authorization bugs, that buggy code might provide access to important assets. Therefore, your plans should include even greater scrutiny when it comes to these kinds of systems. 

Explore actionable patterns and practices from SFI. 

In summary

If you’ve gotten as far as identifying all of your assets, all your applications, and then thinking about the access patterns and controls that you have between them—including authentication, authorization, network isolation, and the use of bug-resistant patterns—you’re in a pretty good place to write a risk summary that can guide your actions for many months. And we haven’t even touched on basic things like vulnerability management, security, bug management, and the usual software lifecycle things that are necessary to keep the system in good health. Combine all of the above and you should have a good-looking risk plan. 

Microsoft
Deputy CISOs

To hear more from Microsoft Deputy CISOs, check out the OCISO blog series:

To stay on top of important security industry updates, explore resources specifically designed for CISOs, and learn best practices for improving your organization’s security posture, join the Microsoft CISO Digest distribution list.

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity. 

¹Microsoft Cyber Signals Issue 9. 

²Microsoft Digital Defense Report 2024.

The post 8 best practices for CISOs conducting risk reviews appeared first on Microsoft Security Blog.

When your infrastructure powers thousands of organizations and millions of users, security is not a feature. It is the foundation you build everything else upon. I’m the Deputy CISO for Microsoft Dynamics 365 and Microsoft Power Platform. You may know Dynamics 365 as a cloud-based suite of intelligent business applications that unify customer relationship management (CRM) and enterprise resource planning (ERP) capabilities to help organizations manage sales, customer service, finance, supply chain, and operations more effectively. Power Platform is a low-code suite of tools that empowers both technical and non-technical users to analyze data, build custom applications, automate workflows, and create intelligent virtual agents. It does this by connecting to various data sources through Microsoft Dataverse and integrating seamlessly with not only Dynamics 365 but Microsoft 365 as well.

What might be a little less obvious is that together, these two suites make up what is quite possibly the largest internal business group fully running on Azure at Microsoft. With such a large cloud footprint of our own, and as an important part of the broader Microsoft cloud offering, it’s highly important that we take our digital security seriously. We must remain vigilant against all manner of threats and align our defenses with Secure Future Initiative (SFI) and One Microsoft principles.

I could talk for quite some time about many aspects of security, but I want to focus in on a topic I see mentioned less often than it should: avoiding attacks of opportunity. These are attacks launched by individuals who find ways into systems adjacent to our domains and who move laterally into our space. Maybe they’re looking for our data itself, or maybe they want to use our space as a means locate the company’s crown jewels elsewhere.

To start with, I’d like to cover credential elimination, endpoint reduction, and identity controls. These are strong security practices that everyone can pick up right away. After that, I want to cover the benefits of platform engineering, which delivers some very important security advantages to organizations ready to take it on.

Credential elimination and the benefits of managed identities

Most attackers don’t break into your network. They log in with stolen credentials. While good password hygiene helps reduce this behavior, a more reliable solution is removing credentials from the system entirely. Internally, we rely on a simple principle: if a workload can authenticate without a secret, it should. In following this principle, we have redesigned standards, retired legacy patterns, and eliminated large classes of passwords, client secrets, and API keys across our environment. The fewer credentials that exist, the fewer there are to phish, guess, reuse, or leak.

In practice, credential elimination is predominantly a design choice. Workloads prove who they are without a shared secret. On Azure, the primary mechanisms we use to accomplish this are managed identities (workload identities issued by Microsoft Entra ID) and federated identity patterns that mint tokens just-in-time, with just-enough-access for a specific resource or scope. There’s nothing to store, rotate, accidentally commit to a repo, or forget to expire—which removes a significant portion of potential incident root causes tied to leaked or stale secrets.

Because so many organizations build on our platforms, eliminating secrets in our own infrastructure is just the beginning. We have lent significant focus to making credential-free patterns available end-to-end for customers too. Power Platform Managed Identity (PPMI) gives Power Platform components like Dataverse plugins and Power Automate a tenant-owned identity that authenticates to Azure resources using federated credentials instead of embedded passwords or client secrets. This reduces outages from expired secrets and unblocks makers who previously needed app registrations they didn’t have permission to create. And Microsoft Entra Agent ID treats AI agents, like those created in Copilot Studio, as first class identities so they can be inventoried, governed, and bound to a human sponsor for accountability.

Credential elimination pairs naturally with endpoint elimination, which is the process of reducing or removing public, inbound-reachable endpoints wherever possible. In Azure, when workloads authenticate using managed identities and call out to services, you can:

• Front your data plane with private endpoints/private link, keeping services off the public internet.
• Disable inbound administrative ports (RDP/SSH) in favor of brokered access like just-in-time, bastion, or serial console, and rely on service-to-service OAuth instead of IP-based allowlists.
• Enforce least privileged access at the token level, minimizing the blast radius of misused tokens.

Together, these tactics result in fewer places for an opportunistic attacker to reach. By replacing secrets with managed identities and collapsing public surfaces, you remove the easiest paths in. There are no passwords to stuff, no shared API keys to reuse, and far fewer public surfaces to probe. Even when an attacker gets a foothold nearby, lateral movement is harder because there’s nothing reusable to log in with, and every agent/workload has a distinct, auditable identity you can shut down in seconds.

Platform engineering for security

Opportunistic attackers thrive on inconsistency. Every exception we grant, whether it’s “this team is special,” or “that pattern is fine just this once,” spawns a snowflake architecture with unique configs, unique libraries, and unique failure modes. At small scale, those choices feel harmless. At organizational scale, they can very likely multiply risk and slow incident response. To win long term, we make opinionated decisions centrally and remove room for interpretation, transforming “do the right thing” from advice to policy.

In practice, that means standardizing on common compute and communications, disallowing brittle patterns, and enforcing the same controls everywhere. When we do that, there are fewer places for misconfigurations to hide, and far fewer opportunities for a nearby compromise to pivot laterally into our environment.

Platform engineering delivers the most benefit at scale. I would estimate the most opportune time to take it on is when you reach 500 engineers. Start too early and you risk dampening healthy experimentation; start too late and migration, coordination, and cleanup get exponentially harder. The inflection point is when the cost of fragmentation overtakes the creative benefits of local team autonomy. That’s the moment to set paved paths, publish the guardrails, and commit to consistency.

What to line up before you flip the switch:

• Paved paths worth choosing, including secure-by-default runtimes, libraries, and pipelines.
• Policy-as-code that blocks deprecated patterns and enforces identity-based auth and networking.
• Executive sponsorship to hold the line on exceptions and keep platform friction low enough that teams see the benefits of using it.

Once you’ve decided the time is right for platform engineering, the next question is “who shapes the platform and how do we make trade‑offs?” This is where security and architecture step in—not as blockers, but as partners in defining the paved paths.

Broadly speaking, product and feature teams tend to optimize for success. They want to add capabilities, integrate faster, and ship value. Platform engineering and security, on the other hand, largely focus on minimizing risk. They want to reduce dependencies, question complexity, and enforce patterns that scale safely. Here’s the important part: neither side is wrong. They’re just solving different problems. The key is finding a deliberate balance that satisfies everyone’s needs. You need enough flexibility for innovation within the right number of guardrails to prevent fragmentation and reduce your attack surface.

This mindset shift is critical because it reframes security from “the team that says no” to “the team that designs the defaults everyone can trust.” When security and platform engineering work together, the result is a foundation where controls are baked in rather than bolted on, and one where every service inherits the same protections by design.

I’ll use my own team’s process as an illustrative example of the process. We standardized compute through “core services,” the backbone our application teams use for execution and communications. The tradeoff is intentional: we get a bit less local flexibility for a lot more global safety and speed. When a new defense is needed, one team lands it in core services and over 450 services inherit it, without the need for a service-by-service campaign. That saves time, reduces duplication, and because the evidence is centralized at the platform level, it’s easier for us to both approve changes and demonstrate compliance. We applied the same approach to partitioning and disallowed patterns, to a common communication library (uniform auth, mTLS, retries, telemetry, and policy hooks), and to centralized resource management and telemetry.

Resilience, consistency, and fewer weak links

Credential elimination and platform engineering aren’t quick wins. They’re foundational moves that reshape how you can defend at scale. They demand long term coordination, but the payoff is resilience, consistency, and a dramatically smaller attack surface. Microsoft continues to innovate in this space as well.

Concerning identity, we have delivered PPMI so organizations can securely access their Azure resources without juggling secrets or certificates—and they can use either bring-your-own or platform-managed identities. Next, we’re moving to platform provisioned identities, which are automatically created for each service, partitioned at the cell level, and scoped to the minimum privileges the service needs. Together, these steps materially reduce blast radius if an attacker gains a foothold.

Standardization is the force multiplier for platform security. Because our core services enforce consistent patterns, one change in the platform can protect all of our 450+ services. This saves time, reduces duplication, makes it easier to approve changes, and helps us demonstrate compliance because evidence is centralized at the platform level. This same uniformity is also enabling agent driven automation to help services meet SFI goals at scale—work that would be impractical in a fragmented environment.

Underpinning all of this is the idea of paved paths: opinionated defaults that make the secure choice the easy choice. That’s how we turn security from a checklist into an enabler, and how we make attacks of opportunity far harder to pull off.

Microsoft
Deputy CISOs

To hear more from Microsoft Deputy CISOs, check out the OCISO blog series.

To stay on top of important security industry updates, explore resources specifically designed for CISOs, and learn best practices for improving your organization’s security posture, join the Microsoft CISO Digest distribution list.

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

The post Making opportunistic cyberattacks harder by design appeared first on Microsoft Security Blog.

Given these rising threats, governments worldwide are advancing policies and regulations to require critical infrastructure organizations to prioritize continuous readiness and proactive defense. The regulatory trajectory is clear. The U.S. National Cybersecurity Strategy published in March 2023 explicitly frames cybersecurity of critical infrastructure as a national security imperative. Japan issued a basic policy to implement the Active Cyber Defense legislation in 2025. Europe continues to implement the NIS2 Directive across the essential sectors. And Canada is advancing a more prescriptive approach to critical infrastructure security through Bill C8.

What Microsoft Threat Intelligence hears from law enforcement agencies reinforces what we observe in our own telemetry. For example, Operation Winter SHIELD is a joint initiative led by the FBI Cyber Division focused on helping CI organizations move from awareness to verified readiness. Implementation not just awareness, not just policy. It is what closes the gap between knowing you are a target and being ready when it matters.

The water sector offers a clear illustration of what that implementation gap looks like in practice and what it takes to close it. The findings from Microsoft, released on March 19, 2026, in collaboration with the Cyber Readiness Institute and the Center on Cyber Technology and Innovation show that hands-on coaching paired with practical training materially improves cyber readiness in water and wastewater utilities in ways that guidance alone does not. When attacks succeed, communities face safety concerns, loss of trust, and service disruptions. That is not an abstraction. That is what is at stake across every CI sector.

To say that environments CI organizations are defending today were not designed for the threat they are facing is an understatement. Legacy systems now operate within hybrid IT–OT environments connected by cloud-based identity, remote access, and complex vendor ecosystems that did not exist when those systems were built. Identity has become the central control layer across all of it. Microsoft Threat Intelligence and Incident Response investigations show a convergence of identity-driven intrusion, living-off-the-land (LOTL) persistence, and nation-state prepositioning across CI. Against this backdrop, five facts define the resilience priorities CI leaders must address in 2026.

Explore CI readiness resources

Five critical threat realities

Five facts CI leaders can’t ignore

Today’s threat landscape reflects five structural realities: identity as the primary entry point, hybrid IT–OT architecture expanding attacker reach, nation-state pre-positioning as an ongoing concern, preventable exposure continuing to drive intrusions, and a shift from data compromise to operational disruption. Together, these dynamics are reshaping critical infrastructure resilience in 2026.

1. Identity is the dominant attack pathway into CI environments

Identity is where we see attackers start, almost every time. In CI environments, identity bridges enterprise IT and operational technology, making it the primary attack path. More than 97% of identity-based attacks target password-based authentication, most commonly through password spray or brute force techniques. As identity systems centralize access to cloud and operational assets, adversaries rely on LOTL techniques and legitimate credentials to evade detection. Because identity now governs access across these connected domains, a single compromised account can provide privileged reach into operationally relevant systems.
 

2. Cloud and hybrid environments expand operational risk

The cloud did not just change how CI organizations operate. It changed how attackers get in and how far they can go. Cloud and hybrid incidents increased 26% in early 2025 as identity, automation, and remote management converged within cloud control planes. Microsoft research shows 18% of intrusions originate from web-facing assets, 12% from exposed remote services, and 3% from supply chain pathways. As long-lived OT systems depend on cloud-based identity and centralized remote access, identity compromise can extend beyond IT into operational environments. Incidents that once remained contained within IT environments can now extend directly into operational systems. For CI operators, this means cloud and hybrid architecture now directly influence operational resilience—not just IT security.

3. Nation-state prepositioning is a strategic reality

This is the one that keeps me up at night. Nation-state operators are actively maintaining long-term, low-visibility access inside U.S. critical infrastructure environments. Microsoft and the Cybersecurity and Infrastructure Security Agency (CISA) have documented campaigns attributed to Volt Typhoon, a PRC state-sponsored actor, in which intruders relied on valid credentials and built-in administrative tools rather than custom malware to evade detection across sectors. Using LOTL techniques and legitimate accounts, these actors embed within routine operations and persist where IT and OT visibility gaps exist. CISA Advisory AA24-038A warns that PRC state-sponsored actors are maintaining persistent access to U.S. critical infrastructure that could be activated during a future crisis. For security leaders, this represents sustained, deliberate positioning inside operational environments and underscores how adversaries shape conditions for future leverage.

4. Exposure and misconfiguration enable initial access

Most of what Microsoft sees in our investigations is not sophisticated. It is preventable. Most intrusions into critical infrastructure begin with preventable exposure rather than advanced exploits. Internet-facing VPNs left enabled too long, contractor identities that outlive project timelines, misconfigured cloud tenants, and dormant privileged accounts create quiet, low-effort entry points. Microsoft research shows that 12% of intrusions originate from exposed remote services. Over time, configuration drift and unmanaged access expand the attack surface, allowing adversaries to gain initial access before persistence or lateral movement is required. Reducing unnecessary exposure remains one of the highest-leverage risk-reduction actions available to CI operators.

5. Operational impact is increasing

The goal has shifted. Attackers are no longer just trying to steal data. They are trying to take things offline. Operational disruption is becoming a primary objective, not a secondary outcome. Attack campaigns surged 87% in early 2025, alongside increased destructive cloud activity and hands-on-keyboard operations targeting critical infrastructure. Identity systems, cloud control planes, and remote management layers are targeted because they provide direct operational leverage. For CI operators, the impact extends beyond data loss to service availability and physical processes. Organizations must ensure operational pathways are resilient against disruptive activity, not only monitored for signs of compromise.

Common attack patterns

Scenario patterns observed in CI environments

These are not hypothetical. They are patterns we see repeatedly in incident response engagements across sectors. The actors may vary. The access pathways do not.

Continuous Readiness approach

Four reinforcing pillars of continuous readiness

Point-in-time hardening does not work against attackers who are playing a long game. In hybrid IT–OT environments, resilience requires sustained practices, not one-time fixes. CI leaders need a continuous approach that strengthens identity, reduces exposure, increases cross-domain visibility, and ensures effective response. Microsoft’s work across critical infrastructure environments consistently highlights four reinforcing pillars:

Readiness validation

Why continuous readiness works

Continuous readiness is most effective when it is grounded in integrated visibility across identity, endpoint, and cloud environments, particularly in hybrid IT–OT architectures common to critical infrastructure. Microsoft’s telemetry enables investigators to correlate activity across these domains, surfacing patterns that isolated tools may miss. CI-informed playbooks, shaped by incident response engagements across sectors, help organizations prioritize the pathways most likely to affect operations. In practice, readiness engagements frequently uncover active or dormant compromise, reinforcing the importance of validating resilience before disruption occurs. For CI leaders, this visibility and correlation are especially critical given the operational consequences of undetected identity misuse or cross‑domain movement.
 

Because adversaries prioritize quiet, long-term access rather than immediate disruption, many organizations only discover exposure after operations are impacted—unless readiness is actively validated.

Next steps

Take action: Validate resilience before it’s tested

Here is what every CI leader reading this should ask themselves: have threat actors already established the access they need and how would I know?

Operational resilience depends on verified assurance, not assumptions. Security leaders must confirm that identity pathways are hardened, exposure is reduced, and adversaries have not established durable footholds. A proactive compromise assessment delivered by Microsoft Incident Response can determine whether adversaries are already present—active or dormant—and help close high-risk gaps before disruption occurs.

For more information, read our blog post, Explore the latest Microsoft Incident Response proactive services for enhanced resilience, or access the CI readiness resources.

Contact your Microsoft representative to schedule a proactive compromise assessment and validate your resilience posture.

Explore resources for CI readiness

The post The threat to critical infrastructure has changed. Has your readiness? appeared first on Microsoft Security Blog.