New Windows Features to Secure Today’s Data in a Post-Quantum World
***July 14 Update: TLS Hybrid Key Exchange using ML-KEM groups is now available on Windows 11 starting with update KB5089573 for 24H2 and 25H2 and KB5095091 for 26H1. Composite algorithms are now available on Windows 11 starting with update KB5095093 for 24H2 and 25H2 and KB5095091 for 26H1. Both features are available for Windows Server 2025 with the July 14th patch - July 14, 2026—KB5099536 (OS Build 26100.33158) Quantum safety is a staged transition across customer environments. Windows is enabling this progression by extending quantum-safe support beyond algorithms and APIs, into the protocols and platform components that organizations use the most. This foundation empowers customers to build, validate, pilot, and ultimately deploy quantum-safe applications, systems, and infrastructure at scale. Microsoft’s earlier announcements introduced PQC support in the core cryptographic building blocks and outlined the broader Quantum Safe Program, including the need for crypto-agility, standards alignment, and a practical migration path. Microsoft delivered a key milestone last November by making PQC algorithms generally available on Windows 11 and Windows Server 2025. Now, we’re bringing quantum-safe capabilities to where they are used: adding PQ TLS hybrid key exchange to the Windows Transport Layer Security (TLS) stack, enabling composite PQC algorithms in Windows cryptography APIs and certificate functions, and bringing the ability to generate PQ certificates via Active Directory Certificate Services (ADCS). Together, these advances help organizations address long-lived data risks now and begin preparing for the broader transition across authentication, certificates, device protection, and management workflows. These updates are part of a broader transition: bringing quantum-safe security into the systems and workflows on which organizations already rely. PQ TLS hybrid key exchange comes to Windows The Windows TLS stack is a core component for secure communication across the platform. Adding PQ TLS hybrid key exchange brings quantum-safe protection to real data-in-transit scenarios that already run on Windows. Hybrid key exchange combines classical and post-quantum algorithms, allowing organizations to begin mitigating HNDL risks. This is especially important for data that must remain confidential for years, as adversaries can capture encrypted traffic today and attempt to decrypt it in the future when quantum computing becomes practical. This reflects Microsoft’s ongoing work in standards development and broader platform investments, including the core cryptographic library SymCrypt, Windows cryptography APIs, and certificate handling. TLS PQ hybrid key exchange is available now in preview through the Windows Insider Program and will become generally available on Windows 11 and Windows Server 2025 in the coming months. These new quantum safe key exchange options can be configured the same way as existing TLS curves (the classical encryption groups already in use today). IT administrators can enable them using familiar Windows management tools: Group Policy for domain-joined enterprise environments, Mobile Device Management (MDM) for modern device management platforms such as Intune, or TLS PowerShell cmdlets (scripted configuration commands) for manual or automated setup. The following hybrid combinations — each pairing a classical algorithm with the post-quantum NIST ML-KEM algorithm to protect against both current and future threats — are available: X25519_MLKEM768 — combines the widely-used X25519 classical algorithm with ML-KEM SecP256r1_MLKEM768 — combines the NIST P-256 elliptic curve with ML-KEM SecP384r1_MLKEM1024 — combines the NIST P-384 elliptic curve with ML-KEM at a higher security level In practical terms, bringing this capability to Windows enables security teams and application owners to evaluate real, Windows-native deployments and begin planning the policy and configuration updates needed for quantum-safe readiness. It provides a direct path to start testing in familiar Windows environments, without relying only on specialized preview stacks. Our TLS supported groups page describes the PQ TLS hybrid key exchange groups available and how to enable them in your environment. Composite PQC algorithms in Windows cryptography APIs Windows cryptography APIs are adding support for composite ML-KEM and composite ML-DSA, where ML‑KEM (Module-Lattice Key Encapsulation Mechanism) and ML‑DSA (Module-Lattice Digital Signature Algorithm) are NIST approved PQ algorithms for key exchange and digital signatures respectively. Composite approaches are important for transition because they allow cryptographic operations to incorporate both classical and post-quantum components. Composite algorithms provide defense in depth by requiring an adversary to break all components to compromise protected data. When implemented natively, they abstract away the complexity of securely combining multiple algorithms, reducing the risk of incorrect integrations and strengthening resilience against weaknesses in individual schemes. This work follows the IETF drafts for composite ML-DSA and composite ML-KEM, to combine the traditional digital signature algorithm ECDSA with ML-DSA and traditional key exchange algorithm ECDHE with ML-KEM. For developers, platform engineers, and security architects, this means Windows-native APIs are moving beyond foundational primitives toward the real-world certificate and signing patterns required in production environments. Composite support enables organizations to prototype new certificate profiles, evaluate trust chain impacts, and prepare for scenarios as relying parties, issuing systems, and policy controls adopt post-quantum capabilities at different speeds. These capabilities are in Windows Insider Preview for Cryptography API Next Generation and certificate functions and will become generally available on Windows 11 and Windows Server 2025 in the coming months. Visit our crypto developers page to learn more and get started. PQ Certificates come to ADCS Active Directory Certificate Services (ADCS) support for issuance of ML‑DSA certificates in Windows Server 2025 is now generally available as of May 2026, bringing PQC support into enterprise public key infrastructure (PKI). ML‑DSA enables quantum‑resistant signing operations across Certification Authorities (CAs) and Online Certificate Status Protocol (OCSP) Responders, providing a practical way to evaluate post‑quantum certificate issuance and trust validation workflows. ADCS supports three ML‑DSA parameter sets (ML‑DSA‑44, ML‑DSA‑65, ML‑DSA‑87), allowing organizations to balance security strength with key and signature size for scenarios like code signing and TLS certificates. PQC support requires newly deployed CAs (as existing CAs cannot be upgraded in place), so organizations can introduce a parallel CA hierarchy alongside existing infrastructure to test and validate deployments without disrupting production workloads. Additional post‑quantum capabilities, including ML‑KEM and composite algorithm support, are planned later this year to expand beyond signing scenarios and enable broader certificate interoperability. What this means for security teams and developers For many organizations, these announcements provide a clear starting point to adopt quantum-safe cryptography. The Windows platform now enables early validation and integration of PQC capabilities across applications and infrastructure. The most effective migrations will be phased. Organizations should start by inventorying where public-key cryptography is used, prioritizing systems that protect sensitive data with long confidentiality lifetimes, and testing hybrid and composite approaches in non-production environments. Security teams can start by identifying where long-lived data is at risk, such as document repositories (e.g., SharePoint), email archives, database systems, and backup or archival storage (including device and cloud backups), and prioritizing the systems that depend on TLS and certificate-based trust. They can then map which applications rely on Windows cryptographic interfaces. Developers can test new algorithm support in controlled environments. IT administrators can prepare for the operational changes required for quantum-safe migration, including across certificates, device policy, performance validation, interoperability testing, and cryptographic inventory management. The goal is not only to adopt new algorithms, but to build crypto-agility into processes so future transitions are easier to manage. These latest Windows capabilities make it easier for that work to begin in a more practical, standards-aligned way. Looking ahead: the next wave of quantum-safe capabilities in Windows These announcements mark early but important steps in bringing quantum-safe capabilities into the Windows scenarios organizations depend on most. Beyond foundational cryptography and PQ hybrid key exchange, that roadmap extends across certificate lifecycle workflows, networking protections such as IPsec and Wi-Fi, authentication scenarios including TLS and Kerberos, passwordless experiences like Windows Hello and passkeys, and platform protections that rely on trusted keys, certificates, and recovery flows. This future direction includes additional capabilities like composite PQ support in ADCS, which will be central to enterprise certificate enrollment and issuance, as well as BitLocker, software signing, and firmware signing. Customers will see progress in some of these areas this year, with additional advancements planned for 2027. Across these investments, the goal remains consistent: to help customers move from algorithm availability to deployable, manageable, enterprise-ready, and quantum-safe solutions. Preparing now for the transition ahead The transition to quantum safety will take time, testing, and close coordination across standards bodies, platform providers, software developers, and enterprise security teams. But momentum matters. By expanding Windows support from foundational post-quantum primitives to real protocol and certificate scenarios, Microsoft is helping make that transition more practical. TLS PQ hybrid key exchange in the Windows TLS stack, composite PQC algorithms in Windows cryptography APIs, and PQC capabilities in ADCS represent important next steps in turning quantum-safe readiness into deployable capability. As the roadmap continues to unfold across certificates, authentication, and platform protection, the best time for organizations to begin preparing is now. Securing today. Preparing for what’s next. Security in Windows is built into the platform - continuously maintained and designed to evolve as threats change. Learn more in the Windows Security book and Windows Server Security book or explore Windows 11, Windows Server, and Copilot+ PCs. For broader solutions, visit the Microsoft Security site, follow the Security blog, or connect with Microsoft Security on LinkedIn and @MSFTSecurity.Registration Open: Community-Led Purview Lightning Talks
Get ready for an electrifying event! The Microsoft Security Community proudly presents Purview Lightning Talks; an action-packed series featuring your fellow Microsoft users, partners and passionate Microsoft Security community members of all sorts. Each 3-12 minute talk cuts straight to the chase, delivering expert insights, real-world use cases, and even a few game-changing tips and tricks. Don’t miss this opportunity to learn, connect, and be inspired! Secure your spot now for the big day: April 30th at 8am Redmond Time. See agenda details below and follow this blog post (sign in and click the "follow" heart in the upper right) to receive notifications. ❗UPDATE❗This event is expected to last around 2 hours and 15 minutes, due to the incredible number of community sessions that were submitted! 💖 Please see the timing table below broken out into sections of four talks each, and plan to arrive 10 minutes before the section that interests you, OR stay for the whole time! Speakers will be available in the chat to answer your questions; please ask your questions during their session. Spillover Q&A forum links will also be shared. The full session recording will be indexed and posted to Microsoft Security Community YouTube within 24 hours after the event. Bookmark this page or follow this blog post for updates! Agenda Legend ↩️ Data Lifecycle Management 🔐 Information Protection 🚫 Data Loss Prevention (DLP) 🦾 Data Security Posture Management (DSPM) for AI 🤖 Purview for AI 👁️ Insider Risk Management (IRM) 🔍 eDiscovery 📊 Governance 🗒️ Compliance Manager 🛡️ Data Security All times are listed in US Pacific/Redmond Time. Session lengths are rounded to the nearest minute. AGENDA Section 1 - approximately 8:00 am - 8:43 am ↩️ The Day Offboarding Exposed Infinite Retention — Nikki Chapple Length: 10 minutes | Topic: Data Lifecycle Management A routine Purview request led to an unexpected discovery: more than 9,000 orphaned OneDrives and thousands of inactive mailboxes still storing content long after employees had left. This talk explains how a retain-only policy created hidden retention debt and how Adaptive Scopes can help organisations separate active users from leavers to avoid similar pitfalls. 🔐 The Purview Label Engine: Automated Classification, Translation, and co-Documentation for Enterprise Tenants — Michael Kirst-Neshva Length: 12 minutes | Topic: Information Protection Global enterprises face the challenge of implementing uniform data protection standards across borders and languages. In this talk, I’ll present a framework that makes Microsoft Purview labels truly scalable. Discover how to roll out parent and child label logics automatically, manage priorities with a single click, and generate instant compliance documentation for every business unit. 🗒️ What's In My Compliance Manager Toolbox: A Cloud Security Architect's Perspective — Jerrad Dahlager Length: 8 minutes | Topic: Compliance Manager A practical walkthrough of how I use Compliance Manager across real client engagements to map controls, track improvement actions, and simplify multi-framework compliance. No theory, just what works in the field. 🛡️ Stop, Think, Protect: Data Security in Real Life with Purview — Oliver Sahlmann Length: 8 minutes | Topic: Data Security With simple labels and matching DLP policies, Purview offers a practical and accessible way to approach data security. This lightning talk uses a real-life traffic light concept to show how a low barrier to adoption can still drive meaningful protection and awareness. Section 2 - approximately 8:44 am - 9:15 am 🔐 Using Purview to prevent oversharing with AI services — Viktor Hedberg Length: 10 minutes | Topic: Information Protection In this day and age, AI is the big thing. However, Copilot has access to everything you can access, including potentially sensitive data. In this session we will look at how to prevent Copilot to access highly sensitive data, using Information Protection. 🦾 How I Helped My Customers Understand their AI Usage (and protect their sensitive data) — Bram de Jager Length: 5 minutes | Topic: Data Security Posture Management (DSPM) for AI As AI tools explode across the web, many organizations still have no idea what’s actually happening in the browser—where employees type prompts, paste sensitive data, or visit public AI sites outside corporate governance. In this lightning talk, I’ll share how I helped customers shine a light on this issue. We’ll explore how Purview Data Security Posture Management (DSPM) can reveal which AI tools employees use, what types of data they input, and where sensitive information may leak through prompts. I’ll walk through real customer scenario where we detected risky AI usage patterns—such as employees pasting confidential documents into public chatbots. 🔐 Four Labels Max for Daily Use: Which Ones & Why? — Romain Dalle Length: 8 minutes | Topic: Information Protection Sensitivity labels are one of the most critical parts of a Purview Risk and compliance deployment, if not the most critical, because it directly impacts how end-users and business units should allow or restrict themselves to share their business data, internally and externally, on a daily basis. Labels have not other options than being precise, meaningful, and balanced in terms of embedded data security. Setting the right taxonomy is core to success, and is everything but a one-time project. 🚫 Data-driven Endpoint DLP Solution with Advanced Hunting — Tatu Seppälä Length: 8 minutes | Topic: Data Loss Prevention (DLP) This lightning talk shows you how to use KQL queries in advanced hunting to easily build initial sensitive service domain groups for authorized and unauthorized domains based on your organization's usage patterns. The same approach can be used for numerous other similar solution refinement and design purposes. Section 3 - approximately 9:16 am - 9:46 am 🔐 The Purview Hack No One Talks About: Container Sensitivity Labels That Fix Oversharing Fast — Nikki Chapple Length: 10 minutes | Topic: Information Protection Most organizations tackle oversharing with manual fixes, but the fastest solution is often overlooked. In this lightning talk, I show how container sensitivity labels automatically apply the right sharing and collaboration controls, ensuring every new Group, Team or SharePoint site starts secure by default. 🔍 Does M365 Support eDiscovery? — Julian Kusenberg Length: 11 minutes | Topic: eDiscovery A myth-busting session that separates perception from reality when it comes to Microsoft 365 eDiscovery capabilities. 📊 Improving Discovery, Trust, and Reuse of Analytics with Purview Data Products — Craig Wyndowe Length: 5 minutes | Topic: Governance This talk shows how bringing Power BI and Fabric assets into Microsoft Purview Governance Domains and Data Products creates a single, trusted view of enterprise analytics. By connecting reports, semantic models, and underlying data with shared metadata, ownership, and business context, organizations can make existing assets easy to discover and safe to reuse. 🔐 Why You Should Create Your Own Sensitive Information Types (SITs) — Niels Jakobsen Length: 5 minutes | Topic: Information Protection An in depth analysis of why Microsoft SITs are not one-size-fits-all, and how to create your own using what Microsoft has already built for you. Section 4 - approximately 9:47 am-10:30 am 👁️ From Zero to First Signal: Insider Risk Management Prerequisites That Actually Matter — Sathish Veerapandian Length: 8 minutes | Topic: Insider Risk Management (IRM) A focused live demo showing the real world prerequisites required for Microsoft Purview Insider Risk Management to work effectively. This session highlights the critical Entra ID, Intune, Microsoft Defender for Endpoint, and Purview DLP configurations that must be in place before creating IRM policies. 🤖 Securing data in the age of AI — Júlio César Gonçalves Vasconcelos Length: 11 minutes | Topic: Purview for AI AI will transform business as we know it; but without proper governance, it can introduce serious risks. We’ll show you how Microsoft Purview enables organizations to accelerate AI adoption while maintaining security, compliance, and transparency. 🔍 Beyond eDiscovery - Purview DSI for Security Investigation — Susantha Silva Length: 11 minutes | Topic: eDiscovery Most people hear “Microsoft Purview” and immediately think compliance, eDiscovery, or legal holds. But this session highlights Data Security Investigations, showing how DSI lets you take a DLP alert or insider risk signal and turn it into a structured investigation. 🚫 Elevating Purview DLP with a real world use case — Victor Wingsing Length: 14 minutes | Topic: Data Loss Prevention (DLP) Learn how I hardened Microsoft Purview DLP beyond out of the box defaults—closing real world data loss gaps, tuning policies to actual user behavior, and turning noisy alerts into protection that really blocks exfiltration. - Quick Closing/ Resource Sharing
How Karambit.AI and Microsoft Bring Software Authenticity to 14 Billion Files Per Month
The Problem: Static Analysis Without Context Traditional static analysis treats every file as an island. Scan a binary, match against known signatures, flag what you recognize. The approach is well-understood and increasingly insufficient against modern threats. The fundamental limitation is the absence of context. Without it, a packer is just a packer. A network call is just a network call. An obfuscation routine is just an obfuscation routine. Whether that behavior is normal or anomalous, whether it belongs in this software, in this ecosystem, performing this function, is invisible to tools that evaluate files in isolation. Attackers exploit this gap. They hide malicious behavior inside legitimate software patterns, evolve their techniques between versions, and distribute intent across multiple components so that no single artifact triggers a detection in a context-free scan. Context-Aware Behavior Analysis Context-aware analysis inverts the model. Instead of asking "is this file bad?" it asks: "is this file behaving the way it should, given everything we know about this ecosystem?" This requires building and maintaining behavioral context across multiple dimensions: Ecosystem-level behavioral baselines: Understanding what behaviors are normal across the entire corpus and which should never appear. In a trusted software ecosystem, obfuscated or packed content is itself an anomaly worth enforcing policy against, regardless of whether the underlying payload is known-malicious. Behavioral chains with low false-positive rates: Individual API calls and instructions are ambiguous in isolation. Context-aware analysis identifies chains of behaviors, sequences where data staging feeds into exfiltration, or where privilege escalation is followed by persistence mechanisms, that reveal intent with high confidence. Cross-file and cross-instance correlation: Behaviors observed in one file are evaluated against patterns seen across millions of other files and scan instances. Shared behavioral fingerprints reveal family relationships, evolutionary lineage, and coordinated campaigns that single-file analysis cannot surface. Historical behavioral deltas: What changed between version N and version N+1? New behaviors in an update, especially behaviors that don't correspond to documented changes, are flagged not because they match a signature, but because they deviate from the established behavioral profile. The result: dramatically higher detection confidence, lower false-positive rates, and the ability to enforce behavioral policy at the ecosystem level. Case Study: Packer_Dictator, Behavioral Detection Under Adversary Adaptation Adversaries must change their Tactics, Techniques, and Procedures (TTPs) over time. When a detection capability catches them, they adapt to evade it. This is expected behavior and it is precisely why general detections at the behavior level are more durable than signature-based approaches. Behavioral patterns are fundamentally harder for adversaries to change without breaking their own tooling. The packer family tracked as packer_dictator illustrates this dynamic clearly. Initial Detection: Obvious Indicators Early variants of packer_dictator used conspicuous binary section names: authoritarian and politically-themed strings that made identification straightforward for anyone examining the PE headers. These were low-hanging indicators, but Karambit.AI's detection wasn't built on them. The system flagged these samples based on their behavioral profile: the entropy characteristics of their packed sections, the structure of their unpacker initialization routines, and the other patterns used to unpack and execute hidden payloads. Adversary Adaptation: Surface Changes, Persistent Behavior As detections rolled out, the users of this packer had to adapted. The obvious section names disappeared, replaced by more benign alternatives: .upx0, standard "unpacked" section names, and other strings designed to blend in with legitimate software. But the underlying behavior didn't change because it couldn't, not without fundamentally rearchitecting the packer itself. Entropy Analysis: Seeing Through Surface Changes Sliding-window entropy analysis reveals why surface-level changes are insufficient to evade behavioral detection. The entropy profiles of packer_dictator samples, even after the section name changes, maintain a characteristic signature: Both profiles exhibit the same structural pattern: a low-entropy region corresponding to the unpacker stub, followed by a sharp transition to a high-entropy plateau spanning the packed payload. This entropy profile is indicative of hidden behaviors, content that has been deliberately obscured, though not necessarily malicious content on its own. The profile shape, transition points, and entropy floor/ceiling ratios form a behavioral fingerprint that persists across variants regardless of metadata changes. Unpacker Initialization: Common Structure Enables Generalized Detection At the disassembly level, packer_dictator variants share a common unpacker initialization sequence that enables generalized analysis across the family. Examining the entry-point code of two samples reveals the structural similarity: Both samples exhibit a characteristic pattern: Register preservation: PUSH R9/PUSH R11 followed by PUSHFQ to save register state and flags before the unpack routine modifies them. Immediate constant loading: Large immediate values loaded into registers (MOV R9, 0x689f8c87eebd998c / MOV R11, 0x6592b8afc22b0736) that serve as decryption keys or XOR masks for the unpacking routine. Arithmetic flag manipulation: Sequences of TEST, NEG, OR, CMP, NOT, and SETNS instructions that compute control flow decisions based on the loaded constants — a form of opaque predicate that obscures the true branch target. Stack-based payload resolution: MOV instructions referencing [RSP + local_120] / [RSP + 0x8] with additional immediate constants written to the stack, setting up parameters for the decompression/decryption loop. The structural template is consistent even as the specific constants, register assignments, and opaque predicate formulations change between variants. This is what makes behavioral detection durable: the adversary can rotate constants and rename sections, but the computational structure required to unpack the payload is constrained by the packer's architecture. By generalizing detection to this structural level, Karambit.AI's engine identifies new packer_dictator variants, and structurally related packer families, without requiring signature updates for each iteration. And this is only one example of the resilience of Karambit.AI’s resilience in the face of constantly advancing adversaries. From Karambyte to Karambiner: Engineering for Billions Karambyte: Building the Context Karambyte was Karambit.AI's original analysis engine, purpose-built for deep behavioral extraction from compiled binaries. Its core function was to extract behavioral context, disassemble control flow, API call chains, entropy profiles, packer identification, behavioral intent classification, and store it for comparison and reference. Karambyte proved the model. It demonstrated that context-aware behavioral analysis could identify threats that traditional static analysis missed, by building rich behavioral profiles and comparing them across software versions and file populations. The system extracted context and maintained it internally, enabling the cross-file and cross-version correlation that drove detections like packer_dictator. But Karambyte's architecture, extracting and storing context within the same system, created a scaling constraint. As adoption grew and the target moved from hundreds of thousands to billions of files per month, the tight coupling between analysis and context storage became the bottleneck. Karambiner: Externalizing Context for Scale Karambiner re-architected the relationship between analysis and context. Rather than each analysis instance maintaining its own behavioral context store, Karambiner externalized the context layer into a dedicated reference that can then be customized for the specific organizational context. This separation enabled three critical capabilities at scale: Horizontal analysis throughput: Analysis scales independently of the context store. Adding processing capacity doesn't require replicating the full behavioral knowledge base. Context enrichment: Behavioral context extracted from collective scans can be used in the massively scalable analysis engine. Ecosystem-wide policy enforcement: With externalized behavioral context, the system can enforce policies across a large-scale ecosystem, such as blocking all obfuscated or packed content. The move from Karambyte to Karambiner was the architectural shift that made scanning of 14 billion files per month possible: a configurable depth of behavioral analysis, with context that scales to the size of the ecosystem rather than the capacity of individual analysis nodes. The Result: Software Behavior Analysis in Microsoft's Pipeline Today, Karambiner is integrated into Microsoft's operational pipeline for build/release and plays a critical role in performing context-aware behavioral analysis across billions of files monthly. The operational impact: Ecosystem-level behavioral policy enforcement: Obfuscated and packed content that has no legitimate reason to exist in the ecosystem is blocked by policy, informed by the scaled behavioral analysis. Durable detection under adversary adaptation: The packer_dictator lineage demonstrates that behavioral detection survives TTP changes that defeat signature-based approaches. Adversaries can change section names, rotate constants, and vary metadata, but the structural behaviors required to execute their payloads remain detectable. Low false-positive rates at scale: Because detection decisions are driven by behavioral understanding and optimizing for scale, the system maintains precision even at 14 billion files per month. Understanding AI capabilities: Behavior analysis can include understanding of where and how AI is used in an ecosystem. Deep understanding of the software going to production: Developers don't always know what components and behaviors make it to the production software, behavior analysis has allowed us to catch unexpected components developers didn’t realize were going to deployment. What's Next The partnership between Karambit.AI and Microsoft demonstrates that context-aware behavior analysis operates on a massive scale in production. As software supply chain attacks grow more sophisticated and adversaries continue evolving their TTPs and the use of AI agents to develop code, the ability to understand what software actually does, in context, across billions of files, is foundational infrastructure. Software authenticity isn't about checking a signature or trusting a certificate. It's about confirming that every binary does what it should, and nothing more. Karambit.AI is the software authenticity platform, ensuring software does only what the developer intended — nothing more. Learn more at karambit.ai.
Microsoft Leads a New Era of Software Supply Chain Transparency
Today, Microsoft announces the general availability of Microsoft’s Signing Transparency (MST) – a first-of-its-kind capability that brings unprecedented visibility and trust to our software supply chain. With this release, Microsoft is leading the industry by recording the build of critical cloud services into a publicly readable and verifiable SCITT standard (Supply Chain Integrity, Transparency, and Trust) compliant blockchain ledger. This means every production software build for in scope services like Azure Attestation and Azure Managed HSM (Hardware Security Module), Azure confidential ledger, Microsoft Signing Transparency itself (and others over time) – is now logged in an immutable, tamper-evident record. Only builds that are in the MST ledger are deployed to production; this gives customers confidence that the supply chain for these critical services can be audited at anytime. Notably, the MST ledger is fully open source and built to align with the emerging IETF SCITT standard. By embracing SCITT’s principles and open protocols, Microsoft ensures that MST not only secures our own ecosystem but also contributes to a broader industry movement toward standardized supply chain transparency. The open-source MST ledger serves as a verifiable trust anchor that any organization or researcher can inspect, audit, or even integrate with their own tooling. MST itself meets the highest levels of transparency, backed by a tamper-proof confidential ledger, open-source, and independently verified. Specifically, we are making the foundation of our trust model transparent and accessible to everyone – reinforcing that trust must be earned through proof, not just promises. This launch marks a major milestone in our commitment to Zero Trust principles, extending “never trust, always verify” all the way into the build itself. Building on a public preview introduced late last year, MST’s general availability delivers verifiable transparency at the software level. It transforms traditional code signing with an additive trust layer that is accessible via an open verification model. Every new software update is accompanied by a publicly auditable proof of integrity, enabling security teams to proactively confirm that each update is authentic and unaltered. To help organizations get the most out of this capability, we are also introducing a free tool to explore the contents – Ledger Explorer – an offline tool that allows security teams to examine MST ledger entries, verify cryptographic proofs, and even validate the ledger’s integrity independently. This tool, combined with MST’s open design, ensures that every Microsoft customer – and the broader community – can hold us accountable in real time for the software we run on their behalf. Key Benefits of Microsoft’s Signing Transparency (MST) Verified Code Integrity – Every software release is cryptographically logged in MST’s ledgers. This makes each build tamper-evident and traceable. If an attacker attempts to inject malicious code or sign an unauthorized update, it will be evident through the well-defined validation step built into the SCITT standard. Organizations gain the assurance that code integrity can be independently confirmed at any time. Independent Verification & Zero Trust – MST enables customers and auditors to verify software authenticity on their own, without having to solely rely on vendor attestations. For each update, Microsoft provides a transparency “receipt” (proof of logging) that you can use to prove the update was officially published and unaltered. This fosters a “don’t just trust, verify” approach, empowering security teams to double-check everything running in their environment aligns with what Microsoft intended. Audit-Trail & Compliance – The transparency ledger creates a permanent, auditable timeline of code deployments. Every entry is a record of what was released and when, backed by cryptographic proofs. This simplifies compliance reporting and accelerates forensic analysis. In the event of an incident, you can quickly audit the ledger to see if any unexpected code was introduced. For highly regulated industries, MST offers concrete evidence of software integrity and policy compliance over time. Leadership & Open Standards – We are delivering real transparency now, encouraging a future where all critical software is released with verifiable integrity. MST’s open source implementation and SCITT-compliant design exemplify our commitment to openness and collaboration. We believe widespread adoption of these standards will strengthen supply chain security for everyone, making trust verification a universal practice. Next Steps Microsoft’s Signing Transparency is more than a new security feature and shapes the advances in trust technology. As threats grow more sophisticated, we must evolve the way we assure our customers about the software they depend on. With MST now generally available, we are leading by example: proving that it is possible to open up the traditionally opaque process of software deployment and turn it into a source of strength and trust, i.e., empowering each person with verifiable transparency. We invite the industry to join us on this journey and get started by reading the documentation and exploring Ledger Explorer today! Together, by embracing transparency and open standards, we can turn “trust but verify” from a slogan into an everyday reality for digital infrastructure.Migrate Sentinel to Defender - Why It Is a Security Architecture Decision, Not Just a Portal Change
Microsoft will retire the Sentinel experience in Azure on March 31, 2027. Most of the conversation around this transition focuses on cost optimization and portal consolidation. That framing undersells what is actually happening. The unified Defender portal is not a new interface for the same capabilities. It is the platform foundation for a fundamentally different SOC operating model — one built on a 2-tier data architecture, graph-based investigation, and AI agents that can hunt, enrich, and respond at machine speed. Partners who understand this will help customers build security programs that match how attackers actually operate. This document covers four things: What the unified experience delivers — the security capabilities that do not exist in standalone Sentinel and why they matter against today’s threats. What the transition really involves - is not data migration, but it is a data architecture project that changes how telemetry flows, where it lives, and who queries it. Where the partner opportunity lives — a structured progression from professional services (transactional, transition execution, and advisory) to ongoing managed security services. Why does the unified experience win competitively — factual capability advantages that give partners a defensible position against third-party SIEM alternatives. The Bigger Picture: Preparing for the Agentic SOC Before getting into transition mechanics, partners need to understand where the industry is headed — because the platform decisions made during this transition will determine whether a customer’s SOC is ready for what comes next. The security industry is moving from human-driven, alert-centric workflows to an operating model built on three pillars: Intellectual Property — the detection logic, hunting hypotheses, response playbooks, and domain expertise that differentiate one security team from another. Human Orchestration — the judgment, context, and decision-making that humans bring to complex incidents. Humans set strategy, validate findings, and make containment decisions. They do not manually triage every alert. AI Agents - built agents that execute repeatable work: enriching incidents, hunting across months of telemetry, validating security posture, drafting response actions, and flagging anomalies for human review. The SOC of 2027 will not be scaled by hiring more analysts. It will be scaled by deploying agents that encode institutional knowledge into automated workflows — orchestrated by humans who focus on the decisions that require judgment. This transformation requires a platform that provides three things: Deep telemetry — agents need months of queryable data to analyze behavioral patterns, build baselines, and detect slow-moving threats. The Sentinel data lake provides this at a cost point that makes long-retention feasible. Relationship context — agents need to understand how entities connect. Which accounts share credentials? What is the blast radius of a compromised service principle? What is the attack path from a phished user to domain admin? Sentinel Graph provides this. Extensibility — partners and customers need to build and deploy their own agents without waiting for Microsoft to ship them. The MCP framework and Copilot agent architecture provide this. None of these exist in Azure experience for Sentinel. All three ship with the Defender experience. The urgency goes beyond the March 2027 deadline. Organizations are deploying AI agents, copilots, and autonomous workflows across their businesses — and every one of those creates a new attack surface. Prompt injection, data poisoning, agent hijacking, cross-plugin exploitation — these are not theoretical risks. They are in the wild today. Defending against AI-powered attacks requires a security platform that is itself AI Agent-ready. The new experience in Defender unlocks this experience. What Unified SIEM and XDR Actually Delivers The original framing — “single pane of glass for SIEM and XDR” — is accurate but insufficient. Here is what the unified platform delivers that standalone Sentinel does not. Cross-Domain Incident Correlation The Defender correlation engine does not just group alerts by time proximity. It builds multi-stage incident graphs that link identity compromise to lateral movement to data exfiltration across SIEM and XDR telemetry — automatically. Consider a token theft chain: an infostealer harvests browser session cookies (endpoint telemetry), the attacker replays the token from a foreign IP (Entra ID sign-in logs), creates a mailbox forwarding rule (Exchange audit logs), and begins exfiltrating data (DLP alerts). In standalone Sentinel, these are four separate alerts in four different tables. In the unified platform, they are one correlated incident with a visual attack timeline. 2-Tier Data Architecture The Sentinel data lake introduces a second storage tier that changes the economics and capabilities of security telemetry: Analytics Tier Data Lake Purpose Real-time detection rules, SOAR, alerting Hunting, forensics, behavioral analysis, AI agent queries Latency Sub-5-minute query and alerting Minutes to hours acceptable Cost ~$4.30/GB PAYG ingestion (~$2.96 at 100 GB/day commitment) ~$0.05/GB ingestion + $0.10/GB data processing (at least 20x cheaper) Retention 90 days default (expensive to extend) Up to 12 years at low cost Best for High-signal, low-volume sources High-volume, investigation-critical sources The architecture decision is not “which tier is cheaper.” It is “which tier gives me the right detection capability for each data source.” Analytics tier candidates: Entra ID sign-in logs, Azure activity, audit logs, EDR alerts, PAM events, Defender for Identity alerts, email threat detections. These need sub-5-minute alerting. Data lake candidates: Raw firewall session logs, full DNS query streams, proxy request logs, Sysmon process events, NSG flow logs. These drive hunting and forensic analysis over weeks or months. Dual-ingest sources: Some sources need both tiers. Entra ID sign-in logs are the canonical example — analytics tier for real-time password spray detection, Data Lake for graph-based blast radius analysis across months of authentication history. Implementation is straightforward: a single Data Collection Rule (DCR) transformation handles the split. One collection point, two routing destinations. The right framing: “Right data in the right tier = better detections AND lower cost.” Cost savings are a side effect of good security architecture, not the goal. Sentinel Graph Sentinel graph enables SOC teams and AI agents to answer questions that flat log queries cannot: What is the blast radius of this compromised account? Which service principals share credentials with the breached identity? What is the attack path from this phished user to domain admin? Which entities are connected to this suspicious IP across all telemetry sources? Graph-based investigation turns isolated alerts into context-rich intelligence. It is the difference between knowing “this account was compromised” and understanding “this account has access to 47 service principals, 3 of which have written access to production Key Vault.” Security Copilot Integration Security Copilot embedded in the defender portal helps analysts summarize incidents, generate hunting queries, explain attacker behavior, and draft response actions. For complex multi-stage incidents, it reduces the time from “I see an alert” to “I understand the full scope” from hours to minutes. With free SCUs available with Microsoft 365 E5, teams can apply AI to the highest-effort investigation work without adding incremental cost. MCP and the Agent Framework The Model Context Protocol (MCP) and Copilot agent architecture let partners and customers build purpose-built security agents. A concrete example: an MCP-enabled agent can automatically enrich a phishing incident by querying email metadata, checking the sender against threat intelligence, pulling the user’s recent sign-in patterns, correlating with Sentinel Graph for lateral risk, and drafting a containment recommendation — in under 60 seconds. This is where partner intellectual property becomes competitive advantage. The agent framework is the mechanism for encoding proprietary detection logic, response playbooks, and domain expertise into automated workflows that run at machine speed. Security Store Security Store allows partners to evolve from one‑time transition projects into repeatable, scalable offerings—supporting professional services, managed services, and agent‑based IP that align with the customer’s unified SecOps operating model As part of the transition, the Microsoft Security Store becomes the extension layer for the Defender —allowing partners to deliver differentiated agents, SaaS, and security services natively within Defender and Sentinel, instead of building and integrating in isolation The 4 Investigation Surfaces: A Customer Maturity Ladder The Sentinel Data Lake exposes four distinct investigation surfaces, each representing a step toward the Agentic SOC — and a partner service opportunity: Surface Capability Maturity Level Partner Opportunity KQL Query Ad-hoc hunting, forensic investigation Basic — “we can query” Hunting query libraries; KQL training Graph Analytics Blast radius, attack paths, entity relationships Intermediate — “we understand relationships” Graph investigation training; attack path workshops Notebooks (PySpark) Statistical analysis, behavioral baselines, ML models Advanced — “we predict behaviors” Custom notebook development; anomaly scoring Agent/MCP Access Autonomous hunting, triage, response at machine speed Agentic SOC — “we automate” Custom agent development; MCP integration The customer who starts with “help us hunt better” ends up at “build us agents that hunt autonomously.” That is the progression from professional services to managed services. What the Transition Actually Involves It is not a data migration — customers’ underlying log data and analytics remain in their existing Log Analytics workspaces. That is important for partners to communicate clearly. But partners should not set the expectation that nothing changes except the URL. Microsoft’s official transition guide documents significant operational changes — including automation rules and playbooks, analytics rule, RBAC restructuring to the new unified model (URBAC), API schema changes that break ServiceNow and Jira integrations, analytics rule transitions where the Fusion engine is replaced by the Defender XDR correlation engine, and data policy shifts for regulated industries. Most customers cannot navigate this complexity without professional help. Important: Transitioning to the Defender portal has no extra cost - estimate the billing with the new Sentinel Cost Estimator Optimizing the unified platform means making deliberate changes: Adding dual-ingest for critical sources that need both real-time detection and long-horizon hunting. Moving high-volume telemetry to the Data Lake — enabling hunting at scale that was previously cost-prohibitive. Retiring redundant data copies where Defender XDR already provides the investigation capability. Updating RBAC, automation, and integrations for the unified portal’s consolidated schema and permission structure. Training analysts on new investigation workflows, Sentinel Graph navigation, and Copilot-assisted triage. Threat Coverage: The Detection Gap Most Organizations Do Not Know They Have This transition is an opportunity to quantify detection maturity — and most organizations will not like what they find. Based on real-world breach analysis — infostealers, business email compromise, human-operated ransomware, cloud identity abuse, vulnerability exploitation, nation-state espionage, and other prevalent threat categories — organizations running standalone Sentinel with default configurations typically have significant detection gaps. Those gaps cluster in three areas: Cross-domain correlation gaps — attacks that span identity, endpoint, email, and cloud workloads. These require the Defender correlation engine because no single log source tells the complete story. Long-retention hunting gaps — threats like command-and-control beaconing and slow data exfiltration that unfold over weeks or months. Analytics-tier retention at 90 days is too expensive to extend and too short for historical pattern analysis. Graph-based analysis gaps — lateral movement, blast radius assessment, and attack path analysis that require understanding entity relationships rather than flat log queries. The unified platform with proper log source coverage across Microsoft-native sources can materially close these gaps — but only if the transition includes a detection coverage assessment, not just a portal cutover. Partners should use MITRE ATT&CK as the common framework for measuring detection maturity. Map existing detections to ATT&CK tactics and techniques before and after transition — a measurable, defensible improvement that justifies advisory fees and ongoing managed services. Partner Opportunity: Professional Services to Managed Services This transition creates a structured progression for all partner types — from professional services that build trust and surface findings, to managed security services that deliver ongoing value. The key insight most partners miss: do not jump from “transition assessment” to “managed services pitch.” Customers are not ready for that conversation until they have experienced the value of professional services. The bridge engagement — whether transactional, transition execution, or advisory — builds trust, demonstrates the expertise, and surfaces the findings that make the managed services conversation a logical next step. Professional Services (transactional + transition execution + advisory) → Managed Security Services (MSSP) The USX transition is the ideal professional services entry point because it combines a mandatory deadline (March 2027) with genuine technical complexity (analytics rule, automation behavioral changes, RBAC restructuring, API schema shifts) that most customers cannot navigate alone. Every engagement produces findings — detection gaps, automation fragility, staffing shortfalls — that are the most credible possible evidence for managed services. Professional Services Transactional Partners Offer Customer Value Key Deliverables Transition Readiness Assessment Risk-mitigated transition with clear scope Sentinel deployment inventory; Defender portal compatibility check; transition roadmap with timeline; MITRE ATT&CK detection coverage baseline Transition Execution and Enablement Accelerated time-to-value, minimal disruption Workspace onboarding; RBAC and automation updates; Dual-portal testing and validation; SOC team training on unified workflows Security Posture and Detection Optimization Better detections and lower cost Data ingestion and tiering strategy; Dual-ingest implementation for critical sources; Detection coverage gap analysis; Automation and Copilot/MCP recommendations Advisory Partners Offer Customer Value Key Deliverables Executive and Strategy Advisory Leadership alignment on why this transition matters Unified SecOps vision and business case; Zero Trust and SOC modernization alignment; Stakeholder alignment across security, IT, and leadership Architecture and Design Advisory Future-ready architecture optimized for the Agentic SOC Target-state 2-tier data architecture; Dual-ingest routing decisions mapped to MITRE tactics; RBAC, retention, and access model design Detection Coverage and Gap Analysis Measurable detection maturity improvement Current-state MITRE ATT&CK coverage mapping; Gap analysis against 24 threat patterns; Detection improvement roadmap with priority recommendations SOC Operating Model Advisory Smooth analyst adoption with clear ownership Redesigned SOC workflows for unified portal; Incident triage and investigation playbooks; RACI for detection engineering, hunting, and platform ops Agentic SOC Readiness Preparation for AI-driven security operations MCP and agent architecture assessment; Custom agent development roadmap; IP + Human Orchestration + Agent operating model design Cost, Licensing and Value Advisory Transparent cost impact with strong business case Current vs. future cost analysis; Data tiering optimization recommendations; TCO and ROI modeling for leadership The conversion to managed services is evidence-based. Every professional services engagement produces findings — detection gaps, automation fragility, staffing shortfalls. Those findings are the most credible possible case for ongoing managed services. Managed Security Services The unified platform changes the managed security conversation. Partners are no longer selling “we watch your alerts 24/7.” They are selling an operating model where proprietary AI agents handle the repeatable work — enrichment, hunting, posture validation, response drafting — and human experts focus on the decisions that require judgment. This is where the competitive moat forms. The formula: IP + Human Orchestration + AI Agents = differentiated managed security. The unified platform enables this through: Multi-tenancy — the built-in multitenant portal eliminates the need for third-party management layers. Sentinel Data Lake — agents can query months of customer telemetry for behavioral analysis without cost constraints. Sentinel Graph — agents can traverse entity relationships to assess blast radius and map attack paths. MCP extensibility — partners can build agents that integrate with proprietary tools and customer-specific systems. Partners who build proprietary agents encoding their detection logic into the MCP framework will differentiate from partners who rely on out-of-box capabilities. The Securing AI Opportunity Organizations are deploying AI agents, copilots, and autonomous workflows across their businesses at an accelerating pace. Every AI deployment creates a new attack surface — prompt injection, data poisoning, agent hijacking, cross-plugin exploitation, unauthorized data access through agentic workflows. These are not theoretical risks. They are in the wild today. Partners who can help customers secure their AI deployments while also using AI to strengthen their SOC will command premium positioning. This requires a security platform that is itself AI Agent-ready — one that can deploy defensive agents at the same pace organizations deploy business AI. The unified Defender portal is that platform. Partners who position USX as “preparing your SOC for AI-driven security operations” will differentiate from partners who position it as “moving to a new portal.” Cost and Operational Benefits Better security architecture also costs less. This is not a contradiction — it is the natural result of putting the right data in the right tier. Benefit How It Works Eliminate low-value ingestion Identify and remove log sources that are never used for detections, investigations, or hunting. Immediately lowers analytics-tier costs without impacting security outcomes. Right-size analytics rules Disable unused rules, consolidate overlapping detections, and remove automation that does not reduce SOC effort. Pay only for processing that delivers measurable security value. Avoid SIEM/XDR duplication Many threats can be investigated directly in Defender XDR without duplicating telemetry into Sentinel. Stop re-ingesting data that Defender already provides. Tier data by detection need Store high-volume, hunt-oriented telemetry in the Data Lake at at least 20x lower cost. Promote only high-signal sources to the analytics tier. Full data fidelity preserved in both tiers. Reduce operational overhead Unified SIEM+XDR workflows in a single portal reduce tool switching, accelerate investigations, simplify analyst onboarding, and enable SOC teams to scale without proportional headcount increases. Improve detection quality The Defender correlation engine produces higher-fidelity incidents with fewer false positives. SOC teams spend less time triaging noise and more time on real threats. Competitive Positioning Partners need defensible talking points when customers evaluate third-party SIEM alternatives. The following advantages are factual, sourced from Microsoft’s transition documentation and platform capabilities — not marketing claims. No extra cost for transitioning — even for non-E5 customers. Third-party SIEM migrations involve licensing, data migration, detection rewrite, and integration rebuild costs. Native cross-domain correlation across Sentinel + Defender products into multi-stage incident graphs. Third-party SIEMs receive Microsoft logs as flat events — they lack the internal signal context, entity resolution, and product-specific intelligence that powers cross-domain correlation. Custom detections across SIEM + XDR — query both Sentinel and Defender XDR tables without ingesting Defender data into Sentinel. Eliminates redundant ingestion cost. Alert tuning extends to Sentinel — previously Defender-only capability, now applicable to Sentinel analytics rules. Net-new noise reduction. Unified entity pages — consolidated user, device, and IP address pages with data from both Sentinel and Defender XDR, plus global search across SIEM and XDR. Third-party SIEMs provide entity views from ingested data only. Built-in multi-tenancy for MSSPs — multitenant portal manages incidents, alerts, and hunting across tenants without third-party management layers. Try out the new GDAP capabilities in Defender portal. Industry validation: Microsoft’s SIEM+XDR platform has been recognized as a Leader by both Forrester (Security Analytics Platforms, 2025) and Gartner (SIEM Magic Quadrant, 2025). Summary: What Partners Should Take Away Topic Key Message Framing USX is a security architecture transformation, not a portal transition. Lead with detection capability, not cost savings. Platform foundation Sentinel Data Lake + Sentinel Graph + MCP/Agent Framework = the platform for the Agentic SOC. 4 investigation surfaces KQL → Graph → Notebooks → Agent/MCP. A maturity ladder from “we can query” to “we automate at machine speed.” Architecture 2-tier data model (analytics + Data Lake) with dual-ingest for critical sources. Cost savings are a side effect of good architecture. Transition complexity Analytics rules and automation rules. API schema changes. RBAC restructuring. Most customers need professional help. Partner engagement model Professional Services (transactional + transition execution + advisory) → Managed Services (MSSP). Competitive positioning No extra cost. Native correlation. Cross-domain detections. Built-in multi-tenancy. Capabilities third-party SIEMs cannot replicate. Partner differentiation IP + Human Orchestration + AI Agents. Partners who build proprietary agents on MCP have competitive advantage. Timeline March 31, 2027. Start now — phased transition with one telemetry domain first, then scale.Level up your Azure Network Security Skills with our Upcoming Webinar Series
As network and application-layer threats continue to evolve, security and infrastructure teams need more than product knowledge. They need practical, scenario-driven guidance they can apply to real workloads. To support that, the Azure Network Security team is hosting a series of upcoming technical webinars covering the capabilities our customers rely on every day: Azure Web Application Firewall (WAF), Azure Firewall, Azure DDoS Protection and Azure Bastion. Each session is focused on demos, the latest enhancements, and the design and operational decisions you face when securing modern Azure environments. Whether you are protecting customer-facing web applications, hardening east-west and egress traffic, or securing remote administrative access at scale, there is a session in this lineup for you. These webinars are ideal for Security Architects and Engineers, Network and Infrastructure teams, SOC Analysts, Cloud Platform Owners, Partner Technical Consultants, and any practitioner responsible for the security posture of workloads running on Azure. Below is the schedule of the upcoming live deliveries. Upcoming Events Azure WAF Layer 7 DDoS defense in practice Date and time: Thursday, June 18, 2026, at 8am PST View event details and join As web applications become primary targets for sophisticated application-layer attacks, Azure Web Application Firewall continues to evolve to meet the needs of modern application security teams facing volumetric and targeted application-layer threats. In this webinar, we will explore how Azure WAF enables a layered, adaptive approach to application-layer DDoS mitigation, helping organizations detect and block malicious request patterns through intelligent inspection, control traffic flow to prevent resource exhaustion from abusive sources, progressively challenge suspicious clients to verify legitimacy without disrupting real users, and combine multiple defense mechanisms into a cohesive mitigation strategy that adapts to evolving attack techniques. Whether you're securing customer-facing web apps or business-critical services, this session will equip you with practical approaches to building resilient application-layer defenses on Azure. Azure Firewall IDPS Detections and Sentinel Integration Date and time: Thursday, July 9, 2026, at 8am PST View event details and join As network threats grow in complexity, organizations need visibility that extends beyond simple traffic filtering into intelligent detection and unified investigation workflows. Azure Firewall's Intrusion Detection and Prevention capabilities continue to evolve to meet the needs of modern security operations teams facing advanced lateral movement, exploitation attempts, and command-and-control activity. In this webinar, we will explore how Azure Firewall identifies malicious network patterns in real time, how detection signals flow seamlessly into Microsoft Sentinel to enrich the broader security narrative, and how security teams can correlate firewall intelligence with other data sources to accelerate threat hunting, streamline incident response, and build a more connected and actionable view of their network security posture. What's New in Azure Bastion Date and time: Thursday, July 23, 2026, at 8am PST View event details and join Secure remote access to cloud workloads remains a critical requirement as organizations scale their Azure environments and adapt to evolving operational demands. Azure Bastion continues to evolve to meet the needs of modern infrastructure teams seeking seamless, browser-based connectivity without exposing virtual machines to the public internet. In this webinar, we'll explore the latest enhancements to Azure Bastion covering new capabilities that improve connectivity options, streamline the administrative experience, expand protocol and session support, and strengthen the overall security posture of remote access workflows. Whether you're managing a handful of VMs or operating at enterprise scale, this session will bring you up to speed on what's new and how these improvements can simplify and secure your day-to-day operations. What's New in Azure Firewall Date and time: Thursday, August 6, 2026, at 8am PST View event details and join As network architectures grow more distributed and threat landscapes more dynamic, organizations need a cloud-native firewall that keeps pace with both modern workload patterns and adversary techniques. Azure Firewall continues to evolve to meet the needs of network and security teams managing hybrid environments, multi-region deployments, and increasingly complex east-west and north-south traffic flows. In this webinar, we will explore the latest enhancements to Azure Firewall covering new policy and rule management capabilities, improvements that expand protocol and traffic inspection coverage, and deeper integrations across the Azure security ecosystem to streamline operations. Whether you are standardizing perimeter protection across a global Azure footprint or modernizing segmentation for business-critical workloads, this session will bring you up to speed on what is new and how these improvements can simplify and strengthen your day-to-day network security operations. What's New in Azure Web Application Firewall Date and time: Thursday, August 27, 2026, at 8am PST View event details and join Web applications remain primary entry points for attackers, and organizations need a Web Application Firewall that adapts as quickly as the threats targeting their workloads. Azure Web Application Firewall continues to evolve to meet the needs of modern application security teams defending against an expanding mix of OWASP-class attacks, automated abuse, and business logic threats across diverse hosting models. In this webinar, we will explore the latest enhancements to Azure WAF. We will cover new detection and rule capabilities that improve protection accuracy, tuning and exclusion improvements that reduce false positives without weakening coverage, and expanded visibility and analytics that accelerate investigation. Whether you are securing customer-facing web apps or managing WAF policies at scale, this session will bring you up to speed on what's new and how these improvements can simplify and strengthen your application protection strategy Past Recordings: View additional past webinars from Azure Network Security on Microsoft Security Community YouTube. Stay connected with the Azure Network Security community Influence product feedback and join the Threat Protection Advisors Program Stay up-to-date and follow the Azure Network Security Blog | Microsoft Community Hub Engage with peers, ask and answer questions in the Azure Network Security discussion board --- Learn and Engage with the Microsoft Security Community Log in and follow this Microsoft Security Community Blog and post/ interact in the Microsoft Security Community discussion spaces. Follow = Click the heart in the upper right when you're logged in 🤍 Join the Microsoft Security Community and be notified of upcoming events, product feedback surveys, and more. Get early access to Microsoft Security products and provide feedback to engineers by joining the Microsoft Security Advisors.. Learn about the Microsoft MVP Program. Join the Microsoft Security Community LinkedIn and the Microsoft Entra Community LinkedIn
Simplifying Code Signing for Windows Apps: Artifact Signing (GA)
Trusted Signing is now Artifact Signing—and it’s officially Generally Available! Artifact Signing is a fully managed, end-to-end code signing service that makes it easier than ever for Windows application developers to sign their apps securely and efficiently. As Artifact Signing rebrands, customers will see changes over the next weeks. Please refer to our Learn docs for the most updated information. What is Artifact Signing? Code signing has traditionally been a complex and manual process. Managing certificates, securing keys, and integrating signing into build pipelines can slow teams down and introduce risk. Artifact Signing changes that by offering a fully managed, end-to-end solution that automates certificate management, enforces strong security controls, and integrates seamlessly with your existing developer tools. With zero-touch certificate management, verified identity, role-based access control, and support for multiple trust models, Artifact Signing makes it easier than ever to build and distribute secure Windows applications. Whether you're shipping consumer apps or internal tools, Artifact Signing helps you deliver software that’s secure. Security Made Simple Zero-Touch Certificate Management No more manual certificate handling. The service provides “zero-touch” certificate management, meaning it handles the creation, protection, and even automatic rotation of code signing certificates on your behalf. These certificates are short-lived and auto renewed behind the scenes, giving you tighter control, faster revocation when needed, and eliminating the risks associated with long-lived certs. Your signing reputation isn’t tied to a single certificate. Instead, it’s anchored to your verified identity in Azure, and every signature reflects that verified identity. Verified Identity Identity validation with Artifact Signing ensures your app’s digital signature displays accurate and verified publisher information. Once validated, your identity details, such as your individual or organization name, are included in the certificate. This means your signed apps will show a verified publisher name, not the dreaded “Unknown Publisher” warning. The entire validation process happens in the Azure portal. You simply submit your individual or organization details, and in some cases, upload supporting documents like business registration papers. Most validations are completed within a few business days, and once approved, you’re ready to start signing your apps immediately. organization validation page Secure and Controlled Signing (RBAC) Artifact Signing enforces Azure’s Role-Based Access Control (RBAC) to secure signing activities. You can assign specific Azure roles to accounts or CI agents that use your Artifact Signing resource, ensuring only authorized developers or build pipelines can initiate signing operations. This tight access control helps prevent unauthorized or rogue signatures. Full Telemetry and Audit Logs Every signing request is tracked. You can see what was signed, when, and by whom in the Azure portal. This logging not only helps with compliance and auditing needs but also enables fast remediation if an issue arises. For example, if you discover a particular signing certificate was used in error or compromised, you can quickly revoke it directly from the portal. The short-lived nature of certificates in Artifact Signing further limits the window of any potential misuse. Artifact Signing gives you enterprise-grade security controls out of the box: strong protection of keys, fine-grained access control, and visibility. For developers and companies concerned about supply chain security, this dramatically reduces risk compared to handling signing keys manually. Built for Developers Artifact Signing was built to slot directly into developers’ existing workflows. You don’t need to overhaul how you build or release software, just plug Artifact Signing into your toolchain: GitHub Actions & Azure DevOps: The service includes first-class support for modern CI/CD. An official GitHub Action is available for easy integration into your workflow YAML, and Azure DevOps has tasks for pipelines. With these tools, every Windows app build can automatically sign binaries or installers—no manual steps required. Since signing credentials are managed in Azure, you avoid storing secrets in your repository. Visual Studio & MSBuild: Use the Artifact Signing client with SignTool to integrate signing into publish profiles or post-build steps. Once the Artifact Signing client is installed, Visual Studio or MSBuild can invoke SignTool as usual, with signatures routed through the Artifact Signing service. SignTool / CLI: Developers using scripts or custom build systems can continue using the familiar signtool.exe command. After a one-time setup, your existing SignTool commands will sign via the cloud service. The actual file signing on your build machine uses a digest signing approach: SignTool computes a hash of your file and sends that to the Artifact Signing service, which returns a signature. The file itself isn’t uploaded, preserving confidentiality and speed. This way, integrating Artifact Signing can be as simple as adding a couple of lines to your build script to point SignTool at Azure. PowerShell & SDK: For advanced automation or custom scenarios, Artifact Signing supports PowerShell modules and an SDK. These tools allow you to script signing operations, bulk-sign files, or integrate signing into specialized build systems. The Right Trust for the Right Audience Artifact Signing has support for multiple trust models to suit different distribution scenarios. You can choose between Public Trust and Private Trust for your code signing, depending on your app’s audience: Public Trust: This is the standard model for software intended to go to consumers. When you use Public Trust signing, the certificates come from a Microsoft CA that’s part of the Microsoft Trusted Root Program. Apps signed under Public Trust are recognized by Windows as coming from a known publisher, enabling a smooth installation experience when security features such as Smart App Control and SmartScreen are enabled. Private Trust: This model is for internal or enterprise apps. These certificates aren’t publicly trusted but are instead meant to work with Windows Defender Application Control (App Control for Business) policies. This is ideal for line-of-business applications, internal tools, or scenarios where you want to tightly control who trusts the app. Artifact Signing ’s Private Trust model is the modern, expanded evolution of Microsoft’s older Device Guard Signing Service (DGSS) -- delivering the same ability to sign internal apps but with ease of access and expanded capabilities. Test Signing: Useful for development and testing. These certificates mimic real signatures but aren’t publicly trusted, allowing you to validate your signing setup in non-production environments before releasing your app. Note on Expanded Scenario Support: Artifact Signing supports additional certificate profiles, including those for VBS enclaves and Private Trust CI Policies. In addition, there is a new preview feature for signing container images using the Notary v2 standard from the CNCF Notary project. This enables developers to sign Docker/OCI container images stored in Azure Container Registry using tools like the notation CLI, backed by Artifact Signing. Having all trust models in one service means you can manage all your signing needs in one place. Whether your code is destined for the world or just your organization, Artifact Signing makes it easy to ensure it is signed with an appropriate level of trust. Misuse and Abuse Management Artifact Signing is engineered with robust safeguards to counter certificate misuse and abuse. The signing platform employs active threat intelligence monitoring to continuously detect suspicious signing activity in real time. The service also emphasizes prevention: certificates are short-lived (renewed daily and valid for only 72 hours), which means any certificate used maliciously can be swiftly revoked without impacting software signed outside its brief lifetime. When misuse is confirmed, Artifact Signing quickly revokes the certificate and suspends the subscriber’s account, removing trust from the malicious code’s signature and stopping further abuse. These measures adhere to strict industry standards for responsible certificate governance. By combining real-time threat detection, built-in preventive controls, and rapid response policies, Artifact Signing gives Windows app developers confidence that any attempt to abuse the platform will be quickly identified and contained, helping protect the broader software ecosystem from emerging threats. Availability and What’s Next Check out the upcoming “What’s New” section in the Artifact Signing Learn Docs for updates on supported file types, new region availability, and more. Microsoft will continue evolving the service to meet developer needs. Conclusion: Enhancing Trust and Security for All Windows Apps Artifact Signing empowers Windows developers to sign their applications with ease and confidence. It integrates effortlessly into your development tools, automates the heavy lifting of certificate management, and ensures every app carries a verified digital signature backed by Microsoft’s Certificate Authorities. For users, it means peace of mind. For developers and organizations, it means fewer headaches, stronger protection against supply chain threats, and complete control over who signs what and when. Now that Artifact Signing is generally available, it’s a must-have for building trustworthy Windows software. It reflects Microsoft’s commitment to a secure, inclusive ecosystem and brings modern security features like Smart App Control and App Control for Business within reach, simply by signing your code. Whether you're shipping consumer apps or internal tools, Artifact Signing helps you deliver software that’s both easy to install and tough to compromise.Introducing new security and compliance add-ons for Microsoft 365 Business Premium
Small and medium businesses (SMBs) are under pressure like never before. Cyber threats are evolving rapidly, and regulatory requirements are becoming increasingly complex. Microsoft 365 Business Premium is our productivity and security solution designed for SMBs (1–300 users). It includes Office apps, Teams, advanced security such as Microsoft Defender for Business, and device management — all in one cost-effective package. Today, we’re taking that a step further. We’re excited to announce three new Microsoft 365 Business Premium add-ons designed to supercharge security and compliance. Tailored for medium-sized organizations, these add-ons bring enterprise-grade security, compliance, and identity protection to the Business Premium experience without the enterprise price tag. Microsoft Defender Suite for Business Premium: $10/user/month Cyberattacks are becoming more complex. Attackers are getting smarter. Microsoft Defender Suite provides end-to-end security to safeguard your businesses from identity attacks, device threats, email phishing, and risky cloud apps. It enables SMBs to reduce risks, respond faster, and maintain a strong security posture without adding complexity. It includes: Protect your business from identity threats: Microsoft Entra ID P2 offers advanced security and governance features including Microsoft Entra ID Protection and Microsoft Entra ID Governance. Microsoft Entra ID protection offers risk-based conditional access that helps block identity attacks in real time using behavioral analytics and signals from both user risk and sign-in risk. It also enables SMBs to detect, investigate, and remediate potential identity-based risks using sophisticated machine learning and anomaly detection capabilities. With detailed reports and alerts, your business is notified of suspicious user activities and sign-in attempts, including scenarios like a password-spray where attackers try to gain unauthorized access to company employee accounts by trying a small number of commonly used passwords across many different accounts. ID Governance capabilities are also included to help automate workflows and processes that give users access to resources. For example, IT admins historically manage the onboarding process manually and generate repetitive user access requests for Managers to review which is time consuming and inefficient. With ID Governance capabilities, pre-configured workflows facilitate the automation of employee onboarding, user access, and lifecycle management throughout their employment, streamlining the process and reducing onboarding time. Microsoft Defender for Identity includes dedicated sensors and connectors for common identity elements that offer visibility into your unique identity landscape and provide detailed posture recommendations, robust detections and response actions. These powerful detections are then automatically enriched and correlated with data from other domains across Defender XDR for true incident-level visibility. Keep your devices safe: Microsoft Defender for Endpoint Plan 2 offers industry-leading antimalware, cyberattack surface reduction, device-based conditional access, comprehensive endpoint detection and response (EDR), advanced hunting with support for custom detections, and attack surface reduction capabilities powered by Secure Score. Secure email and collaboration: With Microsoft Defender for Office 365 P2, you gain access to cyber-attack simulation training, which provides SMBs with a safe and controlled environment to simulate real-world cyber-attacks, helping to train employees in recognizing phishing attempts. Additionally automated response capabilities and post-breach investigations help reduce the time and resources required to identify and remediate potential security breaches. Detailed reports are also available that capture information on employees’ URL clicks, internal and external email distribution, and more. Protect your cloud apps: Microsoft Defender for Cloud Apps is a comprehensive, AI-powered software-as-a-service (SaaS) security solution that enables IT teams to identify and manage shadow IT and ensure that only approved applications are used. It protects against sophisticated SaaS-based attacks, OAuth attacks, and risky interactions with generative AI apps by combining SaaS app discovery, security posture management, app-to-app protection, and integrated threat protection. IT teams can gain full visibility into their SaaS app landscape, understand the risks and set up controls to manage the apps. SaaS security posture management quickly identifies app misconfigurations and provides remediation actions to reduce the attack surface. Microsoft Purview Suite for Business Premium: $10/user/month Protect against insider threats Microsoft Purview Insider Risk Management uses behavioral analytics to detect risky activities, like an employee downloading large volumes of files before leaving the company. Privacy is built in, so you can act early without breaking employee trust. Protect sensitive data wherever it goes Microsoft Purview Information Protection classifies and labels sensitive data, so the right protections follow the data wherever it goes. Think of it as a ‘security tag’ that stays attached to a document whether it’s stored in OneDrive, shared in Teams, or emailed outside the company. Policies can be set based on the ‘tag’ to prevent data oversharing, ensuring sensitive files are only accessible to the right people. Microsoft Purview Data Loss Prevention (DLP) works in the background to stop sensitive information, like credit card numbers or health data, from being accidentally shared with unauthorized people Microsoft Purview Message Encryption adds another layer by making sure email content stays private, even when sent outside the organization. Microsoft Purview Customer Key gives organizations control of their own encryption keys, helping meet strict regulatory requirements. Ensure data privacy and compliant communications Microsoft Purview Communication Compliance monitors and flags inappropriate or risky communications to protect against policy and compliance violations. Protect AI interactions Microsoft Purview Data Security Posture Management (DSPM) for AI provides visibility into how AI interacts with sensitive data, helping detect oversharing, risky prompts, and unethical behavior. Monitors Copilot and third-party AI usage with real-time alerts, policy enforcement, and risk scoring. Manage information through its lifecycle Microsoft Purview Records and Data Lifecycle Management helps businesses meet compliance obligations by applying policies that enable automatic retention or deletion of data. Stay investigation-ready Microsoft Purview eDiscovery (Premium) makes it easier to respond to internal investigations, legal holds, or compliance reviews. Instead of juggling multiple systems, you can search, place holds, and export information in one place — ensuring legal and compliance teams work efficiently. Microsoft Purview Audit (Premium) provides deeper audit logs and analytics to trace activity like file access, email reads, or user actions. This level of detail is critical for incident response and forensic investigations, helping SMBs maintain regulatory readiness and customer trust. Simplify Compliance Management Microsoft Purview Compliance Manager helps track regulatory requirements, assess risk, and manage improvement actions, all in one dashboard tailored for SMBs. Together, these capabilities help SMBs operate with the same level of compliance and data protection as large enterprises but simplified for smaller teams and tighter budgets. Microsoft Defender and Purview Suites for Business Premium: $15/user/month The new Microsoft Defender and Purview Suites unite the full capabilities of Microsoft Defender and Purview into a single, cost-effective package. This all-in-one solution delivers comprehensive security, compliance, and data protection, while helping SMB customers unlock up to 68% savings compared to buying the products separately, making it easier than ever to safeguard your organization without compromising on features or budget. FAQ Q: When will these new add-ons be available for purchase? A: They will be available for purchase as add-ons to Business Premium in September 2025. Q: How can I purchase? A: You can purchase these as add-ons to your Business Premium subscription through Microsoft Security for SMBs website or through your Partner. Q: Are there any seat limits for the add-on offers? A: Yes. Customers can purchase a mix of add-on offers, but the total number of seats across all add-ons is limited to 300 per customer. Q: Does Microsoft 365 Business Premium plus Microsoft Defender Suite allow mixed licensing for endpoint security solutions? A: Microsoft Defender for Business does not support mixed licensing so a tenant with Defender for Business (included in Microsoft 365 Business Premium) along with Defender for Endpoint Plan 2 (included in Microsoft 365 Security) will default to Defender for Business. For example, if you have 80 users licensed for Microsoft 365 Business Premium and you’ve added Microsoft Defender Suite for 30 of those users, the experience for all users will default to Defender for Business. If you would like to change that to the Defender for Endpoint Plan 2 experience, you should license all users for Defender for Endpoint Plan 2 (either through standalone or Microsoft Defender Suite) and then contact Microsoft Support to request the switch for your tenant. You can learn more here. Q: Can customers who purchased the E5 Security Suite as an add-on to Microsoft 365 Business Premium transition to the new Defender Suite starting from the October billing cycle? A: Yes. Customers currently using the Microsoft 365 E5 Security add-on with Microsoft 365 Business Premium are eligible to transition to the new Defender Suite beginning with the October billing cycle. For detailed guidance, please refer to the guidelines here. Q: As a Partner, how do I build Managed Detection and Response (MDR) services with MDB? A: For partners or customers looking to build their own security operations center (SOC) with MDR, Defender for Business supports the streaming of device events (device file, registry, network, logon events and more) to Azure Event Hub, Azure Storage, and Microsoft Sentinel to support advanced hunting and attack detection. If you are using the streaming API for the first time, you can find step-by-step instructions in the Microsoft 365 Streaming API Guide on configuring the Microsoft 365 Streaming API to stream events to your Azure Event Hubs or to your Azure Storage Account. To learn more about Microsoft Security solutions for SMBs you can visit our website.Amazon Security Lake Integration with Microsoft Sentinel: Parquet at the Gates
This blog has been jointly published by ChitreshPandit and Arijit_Paul. In this blog post, we explore how centralized AWS Security Lake data can be transformed and streamed into Microsoft Sentinel using an AWS Lambda-based pipeline for near real-time ingestion. A story of cost, control, and custom engineering at cloud scale Every organization strives to design its security architecture to help address architectural complexity and support cost‑aware, scalable designs, depending on workload characteristics and implementation choices. Across multiple customer environments, we increasingly see a consistent pattern emerge - security telemetry from various AWS services is not ingested in isolation, but is deliberately centralized into Amazon Security Lake. This approach reflects a maturity in design, where organizations move beyond service-level integrations and instead adopt a unified data strategy. Amazon Security Lake enables this by aggregating security data from services such as Route53, WAF, Kubernetes, and others into a centralized, governed repository. The data is normalized and stored in an open, analytics-friendly format, often leveraging Apache Parquet, a columnar storage format optimized for large-scale processing and cost-efficient storage. This can allow organizations to retain high volumes of security data while maintaining performance and may help optimize storage efficiency in certain scenarios, depending on data volume, retention policies, and analytics patterns. However, this architectural choice introduces a new consideration. Microsoft Sentinel, when integrated into such environments, typically expects ingestion through connector-driven pipelines and streaming event models. In contrast, Security Lake represents a batch-oriented, schema-driven data platform. Rather than treating this as a constraint, it becomes an opportunity to rethink how data should flow between these systems. In this blog, we explore how a streaming bridge architecture can be implemented to align Amazon Security Lake with Microsoft Sentinel’s ingestion model. The approach leverages a combination of AWS Lambda and event-driven patterns to process data as it lands in Amazon S3, transforms it into a Sentinel-compatible format, and streams it through Azure Event Hub into Microsoft Sentinel using Data Collection Rules (DCRs) and Data Collection Endpoints (DCEs). This approach can support lower‑latency ingestion patterns when configured appropriately and compared to batch‑only processing models while preserving the lake-first architecture, allowing organizations to support analytics, visualization, and threat hunting activities using the ingested data. For demonstration, this implementation focuses on ingesting the following data sources from Amazon Security Lake: Amazon EKS audit and runtime events Route 53 DNS query logs AWS WAF access logs AWS Lambda execution activity Amazon S3 access events Note: The solution and code provided in this blog are not an officially supported Microsoft solution and do not guarantee performance, reliability, availability, or support. No service-level agreements (SLAs) are included. Readers are responsible for validating suitability for their environment. Before we begin, let us briefly discuss Amazon Security Lake and the Parquet format. Amazon Security Lake and the Parquet Constraint Amazon Security Lake provides a centralized, S3-backed repository for security telemetry, addressing fragmentation across services, accounts, and regions. Instead of service-level ingestion pipelines, logs from sources such as EKS, Route 53, WAF, Lambda, and S3 are aggregated into a single, governed data layer, enabling consistent visibility, separation of duties, and cost-efficient storage at scale. This data is stored in Apache Parquet, a columnar format optimized for analytics—delivering high compression, schema evolution, and efficient, selective reads across engines like Athena and Spark. Microsoft Sentinel operates on a streaming ingestion model expecting JSON payloads, source-specific pipelines, and continuous event flows. In lake-first architectures, reintroducing service-level ingestion is neither practical nor efficient. The requirement, therefore, is to bridge the two models -preserving Parquet for storage while enabling event-driven ingestion at the point of consumption. In the following sections, we will create an Event Hub, Configure the Lambda function and once the streaming is configured in Event Hub we will configure the Data Collection Rules, Data Collection endpoints, Data Collection Rule associations to configure the ingestion pipeline from Event Hub to Sentinel. Pre-requisites: Log Analytics workspace where you have at least contributor rights. Your Log Analytics workspace needs to be linked to a dedicated cluster or to have a commitment tier. Event Hubs namespace that permits public network access. If public network access is disabled, ensure that "Allow trusted Microsoft services to bypass this firewall" is set to "Yes." Event Hubs with events flowing in. In this implementation, events are sent to Event Hubs by the AWS Lambda function configured in the steps below - no manual event sending is required. Appropriate IAM roles in AWS accounts to configure SQS queue, Lambda function, IAM policies, etc. The Event Hub To begin, we need to create an Event Hub. Azure Event Hubs is a fully managed, high-throughput event ingestion and streaming platform, designed to support high event volumes within documented service limits, subject to configuration and tier selection. SKUs (Standard vs Premium) Standard tier is a throughput-unit (TU) based model, where capacity is explicitly controlled and shared across the namespace. Premium tier provides isolated compute and memory via processing units (PU), which can provide more consistent performance characteristics and higher throughput capacity compared to shared models, depending on workload. Additionally, Azure Event Hubs offers a Dedicated tier, which is a fully isolated, single-tenant cluster for enterprise-scale workloads with higher throughputs (at significantly higher cost). Throughput Characteristics (Standard Tier) A single Throughput Unit (TU) provides: Ingress: up to 1 MB/s Egress: up to 2 MB/s A Standard namespace can scale to a maximum of 40 TUs, giving: Max ingress: 40 MB/s Max egress: 80 MB/s All Event Hubs, partitions, and consumers within the namespace share this TU capacity, making it a central ingestion buffer for streaming pipelines rather than a per-source scaling model. Which SKU to choose: For ingress/egress up to 40/80 MB/s, a Standard SKU may be suitable. Higher volumes may warrant consideration of Premium, depending on workload requirements. Azure Event Hubs Concepts: Event Hub Namespace: A logical container that provides the endpoint, networking boundary, and shared throughput capacity (TUs/PUs) for all Event Hubs within it. Event Hub: An individual event stream (topic) within the namespace where events are ingested, stored, and read in a partitioned, ordered manner for parallel processing. Reference: Event Hubs features and terminology - Azure Event Hubs Creating Event Hub namespace, Event Hub entities, and considerations: Create the Azure Event Hub Namespace, in this example, we create a Standard Event Hub with minimum 1 TU with Auto Inflate on enabling scaling upto the maximum 40 TUs. Note the maximum Throughput Units should be based on the size of the logs expected per second from Amazon Security Lake. Since the Event Hub will be used to ingest data in Azure Monitor (Sentinel Workspace) please check the Supported Regions. Ensure Event Hub region alignment with Microsoft Sentinel. Configure TU based on expected ingestion rate Once the Event Hub is created, enable the Local Authentication, since the AWS Lambda code we are using (discussed in the next section) uses Shared access signature to connect to the Azure Event Hub. See Shared Access Signatures. Create individual Event Hubs within the namespace created in Step 1. One Event Hub is required per log type - for example, if Amazon Security Lake includes EKS, Route 53, and WAF logs, then three Event Hub entities should be created. Why this matters: Easier DCR mapping Avoids schema conflicts Create a consumer group in each Event Hub we created in the previous step. Consumer Group is an independent view of an event stream that allows multiple applications to read the same events separately, each maintaining its own position (offset) in the stream. Event Hub Features Avoid using the $Default consumer group. With the Event Hub namespace, entities, and consumer groups in place, the receiving end of the pipeline is ready. The next step is to configure the AWS Lambda function that will translate Security Lake's Parquet files into the JSON events that Event Hub expects. The AWS Lambda Function (SQS-driven Parquet → JSON) In this architecture, AWS Lambda is the translation layer, not an ingestion source. Instead of being invoked directly by S3, Security Lake emits S3 object‑creation notifications into Amazon SQS, and SQS becomes the Lambda trigger. This decoupling is intentional: SQS absorbs bursts of newly written Parquet objects which can help increase resilience of the ingestion pipeline under bursty or variable workloads. Once triggered, the Lambda function processes each queued S3 notification end‑to‑end: it derives the log type from the S3 object key, downloads the Parquet file, converts each row into a discrete JSON event, and forwards the resulting events to Azure Event Hub in batches for downstream ingestion via DCR/DCE. A practical consideration is event size management. Some sources - especially EKS audit telemetry - can carry large, nested fields that are not always useful for Sentinel analytics. For those log types, the Lambda function drops non‑essential fields during transformation to keep each event within Azure ingestion constraints; oversized fields can exceed the 64 KB Azure Monitor field size limit and disrupt ingestion (Fields more than 64 KB will be truncated in Log Analytics Workspace). Solution Architecture The diagram above illustrates the end-to-end data flow: logs originate in AWS, are converted by AWS Lambda, streamed through Azure Event Hub, and stored in Microsoft Sentinel. Amazon Security Lake writes Parquet files to a centralized S3 bucket as logs arrive from source services (CloudTrail, EKS, VPC Flow, WAF, Route 53, and others). Amazon SQS receives S3 event notifications from Security Lake and queues them as Lambda triggers. AWS Lambda picks up each SQS message, identifies the log source from the S3 object key, downloads the Parquet file, converts each row to JSON, and forwards the events to Azure Event Hub. Azure Event Hub receives the JSON events and makes them available for ingestion into Microsoft Sentinel via a Data Collection Rule (DCR). Microsoft Sentinel ingests the data into a custom log table, where it is available for detection rules, hunting queries, and dashboards. The full Lambda function code is available in the GithubRepository-LambdaFunction. Refer to the readme for more details. How the Lambda Function works At a high level, the Lambda function performs four things in sequence for every file it processes: Identify the log source: Security Lake organizes files under a structured S3 key path that includes the log type (for example, CLOUD_TRAIL_MGMT, EKS_AUDIT, VPC_FLOW). The function reads this key path to determine which log source the file belongs to, and routes it to the corresponding Azure Event Hub entity. Files that cannot be matched to a known log type are skipped and logged as warnings. Download and decompress the Parquet file: The function streams the Parquet file from S3 directly to local Lambda storage rather than loading it entirely into memory. This keeps memory consumption bounded regardless of file size. Where Security Lake uses gzip compression, the function decompresses automatically before processing. Convert Parquet rows to JSON: Each row in the Parquet file is read in batches using PyArrow and converted to a JSON object. Parquet columns can carry data types - such as NumPy scalars, nested arrays, and high-precision timestamps — that are not natively serializable to JSON. The function handles these type conversions before serialization, ensuring clean output that Sentinel's ingestion pipeline can accept without errors. Forward events to Azure Event Hub: Converted JSON events are sent to the respective Azure Event Hub entity in batches, with each row becoming a discrete event. The function respects Event Hub's payload size ceiling, handles throttling responses gracefully using retry logic with exponential backoff, and marks each processed file in S3 metadata to prevent duplicate ingestion on retry. Tuning the Lambda Messages at cloud scale are unforgiving. Memory, timeout, batch size, and retry behavior - each decision determines whether the messenger would keep up or fall behind. Several configuration changes are required beyond the default Lambda settings to make this function production-ready. Runtime and Dependencies - Lambda Layer The function depends on three libraries not available in Lambda's default Python runtime: pyarrow (for Parquet reading), pandas (for type handling), and azure-eventhub (for Event Hub connectivity). These are packaged as an AWS Lambda Layer and attached to the function, keeping the deployment package clean and the layer reusable across function versions. Step-by-step instructions for packaging the dependencies, creating the S3 bucket, publishing the Layer, and deploying the function are available in the GithubRepository-LambdaLayer. Secrets Management - AWS Secrets Manager The Azure Event Hub connection strings - one per log type - are sensitive credentials that must not be stored in environment variables in plaintext. The function retrieves them at cold start from AWS Secrets Manager, using a single secret ARN passed as a Lambda environment variable (SECRET_ARN). The secret is stored as a JSON object with each log type as a key. The full secret structure and configuration steps are available in the GithubRepository-SecretsManager. IAM Permissions The Lambda execution IAM role requires scoped permissions across S3, Secrets Manager, SQS, and CloudWatch Logs. Full IAM policy JSON files following the principle of least privilege are available in the GithubRepository-IAMPolicies. Deployment instructions for the IAM Policies are available in the IAM Policies README. Memory Configuration A starting configuration of 1,792 MB is recommended - this is the threshold at which Lambda may allocate a full vCPU. For environments with high log volumes or large Parquet files, increasing to 2,048 MB provides headroom for concurrent batch processing. Tune further based on observed execution durations in CloudWatch Metrics. Timeout Configuration The default Lambda timeout of 3 seconds is insufficient for Parquet processing at scale. The function must download a file from S3, process it in batches, and flush all events to Event Hub - a sequence that can take tens of seconds for larger Security Lake files. A timeout of 5 minutes (300 seconds) is recommended as a starting point, with adjustment based on observed execution durations in CloudWatch Metrics. SQS Trigger Configuration The SQS queue connected to Security Lake S3 event notifications is configured as the trigger for the Lambda function. This enables automatic invocation of the Lambda function whenever Security Lake writes a new Parquet file to S3. Validate Event Hub Ingestion At this point, events should be streaming into each Event Hub. To validate, open a specific Event Hub from the Azure Portal and navigate to the Overview page. You should see active metrics across Requests, Messages, and Throughput, confirming that the Lambda function is successfully forwarding Security Lake events. In the upcoming sections, we will follow the documentation to ingest events from Event Hub to Azure Monitor. Before we begin, please collect the required information as stated here to have resource ID's and other details ready for configuration of DCR and Data Collection Endpoint. Also create a user assigned managed identity (UAMI), since the DCRs in this setup use a UAMI that should be granted the required permissions on the Event Hub Namespace to Receive Events. To grant the Azure Event Hubs Data Receiver role to the user-assigned managed identity, follow the instructions here. Creating Tables in Log Analytics Workspace As mentioned in the Overview, this blog covers the following data sources: Amazon EKS audit and runtime events Route 53 DNS query logs AWS WAF access logs AWS Lambda execution activity Amazon S3 access events The PowerShell scripts to create these tables are provided here: GithubRepo CreateLAWTables. For assistance with executing these scripts, refer to: Readme.md. Note: In the Microsoft Documentation to Ingest logs from EventHub into Azure Monitor only 3 fields are created in the tables (TimeGenerated, RawData, Properties). In this case, the entire Json event from the Event Hub is sent to the RawData field. However the scripts we are running are creating additional fields since we will be parsing the RawData field and extracting/parsing the information from the complete event into individual fields. This makes it easier to search and analyze logs later and schema improves detection rules and KQL efficiency. Create a Data Collection Endpoint To collect data with a data collection rule, you need a data collection endpoint: Create a data collection endpoint. Note: Create the data collection endpoint in the same region as your Log Analytics workspace. From the data collection endpoint's Overview screen, select JSON View. Copy the Resource ID for the data collection rule. You use this information in the next step while creating Data Collection Rules. Create Data Collection Rules Since we have 5 sources in scope for this example, we need to create 5 DCRs using the collected information as stated here, the user assigned managed identity resource ID, and the Data Collection Endpoint resource ID we created in the previous step. DCR Deployment via ARM Templates The Data Collection Rules ARM templates can be found in the GithubRepo-DataCollectionRules. The instructions to create via ARM templates can be found in the readme.md (Microsoft article reference with manual steps here). DCR Mapping (AWS Sources → DCR Templates) ARM Templates in GitHub Repo to AWS Source mapping Data Source DCR Template Name Amazon EKS Logs DCR-awseks.json AWS S3 Access Logs DCR-awsS3access.json AWS WAF Logs DCR-awswaf.json AWS Lambda Execution DCR-lambdaexecution.json Amazon Route 53 Logs DCR-Route53.json Final Step: Associating the Event Hub with the Data Collection Rule At this stage, the core building blocks of the ingestion pipeline are already in place. We have successfully configured streaming to Event Hubs, created dedicated Event Hubs for each Amazon Security Lake source, provisioned destination tables in the Microsoft Sentinel workspace, and defined Data Collection Rules (DCRs) - leveraging the Azure Monitor pipeline and a user-assigned managed identity to securely read incoming events. The final step is to stitch this entire architecture together by establishing associations between the Event Hubs and their corresponding Data Collection Rules. This association links Event Hub to Sentinel, enabling Azure Monitor to actively pull data from the Event Hubs and route it into the defined destination tables. Without this linkage, the pipeline remains incomplete - data may continue to flow into Event Hubs, but it will not be picked up or ingested into Sentinel. Each Event Hub must be explicitly mapped to its respective Data Collection Rule, ensuring: The correct stream is processed by the intended transformation logic Events are routed to the appropriate custom tables The ingestion pipeline operates in a deterministic and scalable manner helping ensure data is routed to the intended destination in a consistent and predictable manner. Once these associations are configured, the end‑to‑end pipeline is intended to operate as designed, subject to configuration accuracy and ongoing operational monitoring— enabling automated ingestion workflows of Amazon Security Lake data into Microsoft Sentinel with minimal manual intervention once configured. Steps to be followed: Associate the data collection rule with the Event Hub To complete the setup, we now associate each Event Hub with its corresponding Data Collection Rule (DCR). This creates the link that allows Azure Monitor to read data from the Event Hub and send it to Microsoft Sentinel. Important: You must create one association per Data Collection Rule. Example: If an Event Hub is receiving AWS Route 53 logs, it must be associated with the DCR created for AWS Route 53. Copy the template from the above link and deploy it to create each Data Collection Rule association. We have to create 1 association per Data Collection Rule. What You Need Event Hub Resource ID Follow these steps to get the Event Hub Resource ID: Open the Event Hub Namespace in the Azure Portal Go to Entities → Event Hubs Select the Event Hub that is receiving the logs (e.g., Route 53 logs) In the Overview page, click on JSON View Copy the Resource ID Resource Group, Region, and Association Name The Resource Group must be the same as the one where the Event Hub is deployed Provide the Azure region where the resources are deployed Define a unique name for the association Data Collection Rule (DCR) Resource ID Open the corresponding Data Collection Rule Go to the Overview page Click on JSON View Copy the Resource ID Key Note: Make sure that Each Event Hub is mapped to the correct DCR The data source and DCR template are aligned (e.g., Route 53 → Route 53 DCR) Validate End-to-End Ingestion Once this configuration is complete, we can validate the logs in the destination table, fields, and parsing accuracy. If you are building on a lake-first security architecture and running into ingestion challenges with Sentinel, feel free to share your experience in the comments or raise an issue in the GitHub repository.
