security
1451 Topics- GenAI vs Cyber Threats: Why GenAI Powered Unified SecOps WinsCybersecurity is evolving faster than ever. Attackers are leveraging automation and AI to scale their operations, so how can defenders keep up? The answer lies in Microsoft Unified Security Operations powered by Generative AI (GenAI). This opens the Cybersecurity Paradox: Attackers only need one successful attempt, but defenders must always be vigilant, otherwise the impact can be huge. Traditional Security Operation Centers (SOCs) are hampered by siloed tools and fragmented data, which slows response and creates vulnerabilities. On average, attackers gain unauthorized access to organizational data in 72 minutes, while traditional defense tools often take on average 258 days to identify and remediate. This is over eight months to detect and resolve breaches, a significant and unsustainable gap. Notably, Microsoft Unified Security Operations, including GenAI-powered capabilities, is also available and supported in Microsoft Government Community Cloud (GCC) and GCC High/DoD environments, ensuring that organizations with the highest compliance and security requirements can benefit from these advanced protections. The Case for Unified Security Operations Unified security operations in Microsoft Defender XDR consolidates SIEM, XDR, Exposure management, and Enterprise Security Posture into a single, integrated experience. This approach allows the following: Breaks down silos by centralizing telemetry across identities, endpoints, SaaS apps, and multi-cloud environments. Infuses AI natively into workflows, enabling faster detection, investigation, and response. Microsoft Sentinel exemplifies this shift with its Data Lake architecture (see my previous post on Microsoft Sentinel’s New Data Lake: Cut Costs & Boost Threat Detection), offering schema-on-read flexibility for petabyte-scale analytics without costly data rehydration. This means defenders can query massive datasets in real time, accelerating threat hunting and forensic analysis. GenAI: A Force Multiplier for Cyber Defense Generative AI transforms security operations from reactive to proactive. Here’s how: Threat Hunting & Incident Response GenAI enables predictive analytics and anomaly detection across hybrid identities, endpoints, and workloads. It doesn’t just find threats—it anticipates them. Behavioral Analytics with UEBA Advanced User and Entity Behavior Analytics (UEBA) powered by AI correlates signals from multi-cloud environments and identity providers like Okta, delivering actionable insights for insider risk and compromised accounts. [13 -Micros...s new UEBA | Word] Automation at Scale AI-driven playbooks streamline repetitive tasks, reducing manual workload and accelerating remediation. This frees analysts to focus on strategic threat hunting. Microsoft Innovations Driving This Shift For SOC teams and cybersecurity practitioners, these innovations mean you spend less time on manual investigations and more time leveraging actionable insights, ultimately boosting productivity and allowing you to focus on higher-value security work that matters most to your organization. Plus, by making threat detection and response faster and more accurate, you can reduce stress, minimize risk, and demonstrate greater value to your stakeholders. Sentinel Data Lake: Unlocks real-time analytics at scale, enabling AI-driven threat detection without rehydration costs. Microsoft Sentinel data lake overview UEBA Enhancements: Multi-cloud and identity integrations for unified risk visibility. Sentinel UEBA’s Superpower: Actionable Insights You Can Use! Now with Okta and Multi-Cloud Logs! Security Copilot & Agentic AI: Harnesses AI and global threat intelligence to automate detection, response, and compliance across the security stack, enabling teams to scale operations and strengthen Zero Trust defenses defenders. Security Copilot Agents: The New Era of AI, Driven Cyber Defense Sector-Specific Impact All sectors are different, but I would like to focus a bit on the public sector at this time. This sector and critical infrastructure organizations face unique challenges: talent shortages, operational complexity, and nation-state threats. GenAI-centric platforms help these sectors shift from reactive defense to predictive resilience, ensuring mission-critical systems remain secure. By leveraging advanced AI-driven analytics and automation, public sector organizations can streamline incident detection, accelerate response times, and proactively uncover hidden risks before they escalate. With unified platforms that bridge data silos and integrate identity, endpoint, and cloud telemetry, these entities gain a holistic security posture that supports compliance and operational continuity. Ultimately, embracing generative AI not only helps defend against sophisticated cyber adversaries but also empowers public sector teams to confidently protect the services and infrastructure their communities rely on every day. Call to Action Artificial intelligence is driving unified cybersecurity. Solutions like Microsoft Defender XDR and Sentinel now integrate into a single dashboard, consolidating alerts, incidents, and data from multiple sources. AI swiftly correlates information, prioritizes threats, and automates investigations, helping security teams respond quickly with less manual work. This shift enables organizations to proactively manage cyber risks and strengthen their resilience against evolving challenges. Picture a single pane of glass where all your XDRs and Defenders converge, AI instantly shifts through the noise, highlighting what matters most so teams can act with clarity and speed. That may include: Assess your SOC maturity and identify silos. Use the Security Operations Self-Assessment Tool to determine your SOC’s maturity level and provide actionable recommendations for improving processes and tooling. Also see Security Maturity Model from the Well-Architected Framework Explore Microsoft Sentinel, Defender XDR, and Security Copilot for AI-powered security. Explains progressive security maturity levels and strategies for strengthening your security posture. What is Microsoft Defender XDR? - Microsoft Defender XDR and What is Microsoft Security Copilot? Design Security in Solutions from Day One! Drive embedding security from the start of solution design through secure-by-default configurations and proactive operations, aligning with Zero Trust and MCRA principles to build resilient, compliant, and scalable systems. Design Security in Solutions from Day One! Innovate boldly, Deploy Safely, and Never Regret it! Upskill your teams on GenAI tools and responsible AI practices. Guidance for securing AI apps and data, aligned with Zero Trust principles Build a strong security posture for AI About the Author: Hello Jacques "Jack” here! I am a Microsoft Technical Trainer focused on helping organizations use advanced security and AI solutions. I create and deliver training programs that combine technical expertise with practical use, enabling teams to adopt innovations like Microsoft Sentinel, Defender XDR, and Security Copilot for stronger cyber resilience. #SkilledByMTT #MicrosoftLearn
- Secure external attachments with Purview encryptionIf you are using Microsoft Purview to secure email attachments, it’s important to understand how Conditional Access (CA) policies and Guest account settings influence the experience for external recipients. Scenario 1: Guest Accounts Enabled ✅ Smooth Experience Each recipient is provisioned with a guest account, allowing them to access the file seamlessly. 📝 Note This can result in a significant increase in guest users, potentially in hundreds or thousands, which may create additional administrative workload and management challenges. Scenario 2: No Guest Accounts 🚫 Limited Access External users can only view attachments via the web interface. Attempts to download then open the files in Office apps typically fail due to repeated credential prompts. 🔍 Why? Conditional Access policies may block access to Microsoft Rights Management Services because it is included under All resources. This typically occurs when access controls such as Multi-Factor Authentication (MFA) or device compliance are enforced, as these require users or guests to authenticate. To have a better experience without enabling guest accounts, consider adjusting your CA policy with one of the below approaches: Recommended Approach Exclude Microsoft Rights Management Services from CA policies targeting All resources. Alternative Approach Exclude Guest or External Users → Other external users from CA policies targeting All users. Things to consider These access blocks won’t appear in sign-in logs— as this type of external users leave no trace. Manual CA policy review is essential. Using What if feature with the following conditions can help to identify which policies need to be modified. These approaches only apply to email attachments. For SharePoint Online hosted files, guest accounts remain the only viable option. Always consult your Identity/Security team before making changes to ensure no unintended impact on other workloads. References For detailed guidance on how guest accounts interact with encrypted documents, refer to Microsoft’s official documentation: 🔗 Microsoft Entra configuration for content encrypted by Microsoft Purview Information Protection | Microsoft Learn495Views3likes3Comments
- Question behavior same malwareTwo malware with the same detection name but on different PCs and files, do they behave differently or the same? Example: Two detections of Trojan:Win32/Wacatac.C!ml 1) It remains latent in standby mode, awaiting commands. 2) It modifies, deletes, or corrupts files.29Views0likes3Comments
- Trusted Signing Public Preview UpdateNearly a year ago we announced the Public Preview of Trusted Signing with availability for organizations with 3 years or more of verifiable history to onboard to the service to get a fully managed code signing experience to simplify the efforts for Windows app developers. Over the past year, we’ve announced new features including the Preview support for Individual Developers, and we highlighted how the service contributes to the Windows Security story at Microsoft BUILD 2024 in the Unleash Windows App Security & Reputation with Trusted Signing session. During the Public Preview, we have obtained valuable insights on the service features from our customers, and insights into the developer experience as well as experience for Windows users. As we incorporate this feedback and learning into our General Availability (GA) release, we are limiting new customer subscriptions as part of the public preview. This approach will allow us to focus on refining the service based on the feedback and data collected during the preview phase. The limit in new customer subscriptions for Trusted Signing will take effect Wednesday, April 2, 2025, and make the service only available to US and Canada-based organizations with 3 years or more of verifiable history. Onboarding for individual developers and all other organizations will not be directly available for the remainder of the preview, and we look forward to expanding the service availability as we approach GA. Note that this announcement does not impact any existing subscribers of Trusted Signing, and the service will continue to be available for these subscribers as it has been throughout the Public Preview. For additional information about Trusted Signing please refer to Trusted Signing documentation | Microsoft Learn and Trusted Signing FAQ | Microsoft Learn.5.2KViews7likes21Comments
- Windows 11, version 25H2 security baselineMicrosoft is pleased to announce the security baseline package for Windows 11, version 25H2! You can download the baseline package from the Microsoft Security Compliance Toolkit, test the recommended configurations in your environment, and customize / implement them as appropriate. Summary of changes This release includes several changes made since the Windows 11, version 24H2 security baseline to further assist in the security of enterprise customers, to include better alignment with the latest capabilities and standards. The changes include what is depicted in the table below. Security Policy Change Summary Printer: Impersonate a client after authentication Add “RESTRICTED SERVICES\PrintSpoolerService” to allow the Print Spooler’s restricted service identity to impersonate clients securely NTLM Auditing Enhancements Enable by default to improve visibility into NTLM usage within your environment MDAV: Attack Surface Reduction (ASR) Add "Block process creations originating from PSExec and WMI commands" (d1e49aac-8f56-4280-b9ba-993a6d77406c) with a recommended value of 2 (Audit) to improve visibility into suspicious activity MDAV: Control whether exclusions are visible to local users Move to Not Configured as it is overridden by the parent setting MDAV: Scan packed executables Remove from the baseline because the setting is no longer functional - Windows always scans packed executables by default Network: Configure NetBIOS settings Disable NetBIOS name resolution on all network adapters to reduce legacy protocol exposure Disable Internet Explorer 11 Launch Via COM Automation Disable to prevent legacy scripts and applications from programmatically launching Internet Explorer 11 using COM automation interfaces Include command line in process creation events Enable to improve visibility into how processes are executed across the system WDigest Authentication Remove from the baseline because the setting is obsolete - WDigest is disabled by default and no longer needed in modern Windows environments Printer Improving Print Security with IPPS and Certificate Validation To enhance the security of network printing, Windows introduces two new policies focused on controlling the use of IPP (Internet Printing Protocol) printers and enforcing encrypted communications. The setting, "Require IPPS for IPP printers", (Administrative Templates\Printers) determines whether printers that do not support TLS are allowed to be installed. When this policy is disabled (default), both IPP and IPPS transport printers can be installed - although IPPS is preferred when both are available. When enabled, only IPPS printers will be installed; attempts to install non-compliant printers will fail and generate an event in the Application log, indicating that installation was blocked by policy. The second policy, "Set TLS/SSL security policy for IPP printers" (same policy path) requires that printers present valid and trusted TLS/SSL certificates before connections can be established. Enabling this policy defends against spoofed or unauthorized printers, reducing the risk of credential theft or redirection of sensitive print jobs. While these policies significantly improve security posture, enabling them may introduce operational challenges in environments where IPP and self-signed or locally issued certificates are still commonly used. For this reason, neither policy is enforced in the security baseline, at this time. We recommend that you assess your printers, and if they meet the requirements, consider enabling those policies with a remediation plan to address any non-compliant printers in a controlled and predictable manner. User Rights Assignment Update: Impersonate a client after authentication We have added RESTRICTED SERVICES\PrintSpoolerService in the “Impersonate a client after authentication” User Rights Assignment policy. The baseline already includes Administrators, SERVICE, LOCAL SERVICE, and NETWORK SERVICE for this user right. Adding the restricted Print Spooler supports Microsoft’s ongoing effort to apply least privilege to system services. It enables Print Spooler to securely impersonate user tokens in modern print scenarios using a scoped, restricted service identity. Although this identity is associated with functionality introduced as part of Windows Protected Print (WPP), it is required to support proper print operations even if WPP is not currently enabled. The system manifests the identity by default, and its presence ensures forward compatibility with WPP-based printing. Note: This account may appear as a raw SID (e.g., S-1-5-99-...) in Group Policy or local policy tools before the service is fully initialized. This is expected and does not indicate a misconfiguration. Warning: Removing this entry will result in print failures in environments where WPP is enabled. We recommend retaining this entry in any custom security configuration that defines this user right. NTLM Auditing Enhancements Windows 11, version 25H2 includes enhanced NTLM auditing capabilities, enabled by default, which significantly improves visibility into NTLM usage within your environment. These enhancements provide detailed audit logs to help security teams monitor and investigate authentication activity, identify insecure practices, and prepare for future NTLM restrictions. Since these auditing improvements are enabled by default, no additional configuration is required, and thus the baseline does not explicitly enforce them. For more details, see Overview of NTLM auditing enhancements in Windows 11 and Windows Server 2025. Microsoft Defender Antivirus Attack Surface Reduction (ASR) In this release, we've updated the Attack Surface Reduction (ASR) rules to add the policy Block process creations originating from PSExec and WMI commands (d1e49aac-8f56-4280-b9ba-993a6d77406c) with a recommended value of 2 (Audit). By auditing this rule, you can gain essential visibility into potential privilege escalation attempts via tools such as PSExec or persistence mechanisms using WMI. This enhancement helps organizations proactively identify suspicious activities without impacting legitimate administrative workflows. Control whether exclusions are visible to local users We have removed the configuration for the policy "Control whether exclusions are visible to local users" (Windows Components\Microsoft Defender Antivirus) from the baseline in this release. This change was made because the parent policy "Control whether or not exclusions are visible to Local Admins" is already set to Enabled, which takes precedence and effectively overrides the behavior of the former setting. As a result, explicitly configuring the child policy is unnecessary. You can continue to manage exclusion visibility through the parent policy, which provides the intended control over whether local administrators can view exclusion lists. Scan packed executables The “Scan packed executables” setting (Windows Components\Microsoft Defender Antivirus\Scan) has been removed from the security baseline because it is no longer functional in modern Windows releases. Microsoft Defender Antivirus always scans packed executables by default, therefore configuring this policy has no effect on the system. Disable NetBIOS Name Resolution on All Networks In this release, we start disabling NetBIOS name resolution on all network adapters in the security baseline, including those connected to private and domain networks. The change is reflected in the policy setting “Configure NetBIOS settings” (Network\DNS Client). We are trying to eliminate the legacy name resolution protocol that is vulnerable to spoofing and credential theft. NetBIOS is no longer needed in modern environments where DNS is fully deployed and supported. To mitigate potential compatibility issues, you should ensure that all internal systems and applications use DNS for name resolution. We recommend the following; test critical workflows in a staging environment prior to deployment, monitor for any resolution failures or fallback behavior, and inform support staff of the change to assist with troubleshooting as needed. This update aligns with our broader efforts to phase out legacy protocols and improve security. Disable Internet Explorer 11 Launch Via COM Automation To enhance the security posture of enterprise environments, we recommend disabling Internet Explorer 11 Launch Via COM Automation (Windows Components\Internet Explorer) to prevent legacy scripts and applications from programmatically launching Internet Explorer 11 using COM automation interfaces such as CreateObject("InternetExplorer.Application"). Allowing such behavior poses a significant risk by exposing systems to the legacy MSHTML and ActiveX components, which are vulnerable to exploitation. Include command line in process creation events We have enabled the setting "Include command line in process creation events" (System\Audit Process Creation) in the baseline to improve visibility into how processes are executed across the system. Capturing command-line arguments allows defenders to detect and investigate malicious activity that may otherwise appear legitimate, such as abuse of scripting engines, credential theft tools, or obfuscated payloads using native binaries. This setting supports modern threat detection techniques with minimal performance overhead and is highly recommended. WDigest Authentication We removed the policy "WDigest Authentication (disabling may require KB2871997)" from the security baseline because it is no longer necessary for Windows. This policy was originally enforced to prevent WDigest from storing user’s plaintext passwords in memory, which posed a serious credential theft risk. However, starting with 24H2 update, the engineering teams deprecated this policy. As a result, there is no longer a need to explicitly enforce this setting, and the policy has been removed from the baseline to reflect the current default behavior. Since the setting does not write to the normal policies location in the registry it will not be cleaned up automatically for any existing deployments. Please let us know your thoughts by commenting on this post or through the Security Baseline Community.7.1KViews6likes8Comments
- Question malware detected Defender for Windows 10Why did my Microsoft Defender detect a malicious file in AppData\Roaming\Secure\QtWebKit4.dll (Trojan:Win32/Wacatac.C!ml) during a full scan and the Kaspersky Free and Malwarebytes Free scans didn't detect it? Was it maliciously modifying, corrupting, or deleting various files on my PC before detection? I sent it to Virus Total, the hash: 935cd9070679168cfcea6aea40d68294ae5f44c551cee971e69dc32f0d7ce14b Inside the same folder as this DLL, there's another folder with a suspicious file, Caller.exe. I sent it to Virus Total, and only one detection from 72 antivirus programs was found, with the name TrojanPSW.Rhadamanthys. VT hash: d2251490ca5bd67e63ea52a65bbff8823f2012f417ad0bd073366c02aa0b382846Views0likes2Comments
- Blog Series: Securing the Future: Protecting AI Workloads in the EnterprisePost 1: The Hidden Threats in the AI Supply Chain Your AI Supply Chain Is Under Attack — And You Might Not Even Know It Imagine deploying a cutting-edge AI model that delivers flawless predictions in testing. The system performs beautifully, adoption soars, and your data science team celebrates. Then, a few weeks later, you discover the model has been quietly exfiltrating sensitive data — or worse, that a single poisoned dataset altered its decision-making from the start. This isn’t a grim sci-fi scenario. It’s a growing reality. AI systems today rely on a complex and largely opaque supply chain — one built on shared models, open-source frameworks, third-party datasets, and cloud-based APIs. Each link in that chain represents both innovation and vulnerability. And unless organizations start treating the AI supply chain as a security-critical system, they risk building intelligence on a foundation they can’t fully trust. Understanding the AI Supply Chain Much like traditional software, modern AI models rarely start from scratch. Developers and data scientists leverage a mix of external assets to accelerate innovation — pretrained models from public repositories like Hugging Face (https://huggingface.co/), data from external vendors, third-party labeling services, and open-source ML libraries. Each of these layers forms part of your AI supply chain — the ecosystem of components that power your model’s lifecycle, from data ingestion to deployment. In many cases, organizations don’t fully know: Where their datasets originated. Whether the pretrained model they fine-tuned was modified or backdoored. If the frameworks powering their pipeline contain known vulnerabilities. AI’s strength — its openness and speed of adoption — is also its greatest weakness. You can’t secure what you don’t see, and most teams have very little visibility into the origins of their AI assets. The New Threat Landscape Attackers have taken notice. As enterprises race to operationalize AI, threat actors are shifting their attention from traditional IT systems to the AI layer itself — particularly the model and data supply chain. Common attack vectors now include: Data poisoning: Injecting subtle malicious samples into training data to bias or manipulate model behavior. Model backdoors: Embedding hidden triggers in pretrained models that can be activated later. Dependency exploits: Compromising widely used ML libraries or open-source repositories. Model theft and leakage: Extracting proprietary weights or exploiting exposed inference APIs. These attacks are often invisible until after deployment, when the damage has already been done. In 2024, several research teams demonstrated how tampered open-source LLMs could leak sensitive data or respond with biased or unsafe outputs — all due to poisoned dependencies within the model’s lineage. The pattern is clear: adversaries are no longer only targeting applications; they’re targeting the intelligence that drives them. Why Traditional Security Approaches Fall Short Most organizations already have strong DevSecOps practices for traditional software — automated scanning, dependency tracking, and secure Continuous Integration/Continuous Deployment (CI/CD) pipelines. But those frameworks were never designed for the unique properties of AI systems. Here’s why: Opacity: AI models are often black boxes. Their behavior can change dramatically from minor data shifts, making tampering hard to detect. Lack of origin: Few organizations maintain a verifiable “family tree” of their models and datasets. Limited tooling: Security tools that detect code vulnerabilities don’t yet understand model weights, embeddings, or training lineage. In other words: You can’t patch what you can’t trace. The absence of traceability leaves organizations flying blind — relying on trust where verification should exist. Securing the AI Supply Chain: Emerging Best Practices The good news is that a new generation of frameworks and controls is emerging to bring security discipline to AI development. The following strategies are quickly becoming best practices in leading enterprises: Establish Model Origin and Integrity Maintain a record of where each model originated, who contributed to it, and how it’s been modified. Implement cryptographic signing for model artifacts. Use integrity checks (e.g., hash validation) before deploying any model. Incorporate continuous verification into your MLOps pipeline. This ensures that only trusted, validated models make it to production. Create a Model Bill of Materials (MBOM) Borrowing from software security, an MBOM documents every dataset, dependency, and component that went into building a model — similar to an SBOM for code. Helps identify which datasets and third-party assets were used. Enables rapid response when vulnerabilities are discovered upstream. Organizations like NIST, MITRE, and the Cloud Security Alliance are developing frameworks to make MBOMs a standard part of AI risk management. NIST AI Risk Management Framework (AI RMF) https://www.nist.gov/itl/ai-risk-management-framework NIST AI RMF Playbook https://www.nist.gov/itl/ai-risk-management-framework/nist-ai-rmf-playbook MITRE AI Risk Database (with Robust Intelligence) https://www.mitre.org/news-insights/news-release/mitre-and-robust-intelligence-tackle-ai-supply-chain-risks MITRE’s SAFE-AI Framework https://atlas.mitre.org/pdf-files/SAFEAI_Full_Report.pdf Cloud Security Alliance – AI Model Risk Management Framework https://cloudsecurityalliance.org/artifacts/ai-model-risk-management-framework Secure Your Data Supply Chain The quality and integrity of training data directly shape model behavior. Validate datasets for anomalies, duplicates, or bias. Use data versioning and lineage tracking for full transparency. Where possible, apply differential privacy or watermarking to protect sensitive data. Remember: even small amounts of corrupted data can lead to large downstream risks. Evaluate Third-Party and Open-Source Dependencies Open-source AI tools are powerful — but not always trustworthy. Regularly scan models and libraries for known vulnerabilities. Vet external model vendors and require transparency about their security practices. Treat external ML assets as untrusted code until verified. A simple rule of thumb: if you wouldn’t deploy a third-party software package without security review, don’t deploy a third-party model that way either. The Path Forward: Traceability as the Foundation of AI Trust AI’s transformative potential depends on trust — and trust depends on visibility. Securing your AI supply chain isn’t just about compliance or risk mitigation; it’s about protecting the integrity of the intelligence that drives business decisions, customer interactions, and even national infrastructure. As AI becomes the engine of enterprise innovation, we must bring the same rigor to securing its foundations that we once brought to software itself. Every model has a lineage. Every lineage is a potential attack path. In the next post, we’ll explore how to apply DevSecOps principles to MLOps pipelines — securing the entire AI lifecycle from data collection to deployment. Key Takeaway The AI supply chain is your new attack surface. The only way to defend it is through visibility, origin, and continuous validation — before, during, and after deployment. Contributors Juan José Guirola Sr. (Security GBB for Advanced Identity - Microsoft) References Hugging Face - https://huggingface.co/ Research Gate - https://www.researchgate.net/publication/381514112_Exploiting_Privacy_Vulnerabilities_in_Open_Source_LLMs_Using_Maliciously_Crafted_Prompts/fulltext/66722cb1de777205a338bbba/Exploiting-Privacy-Vulnerabilities-in-Open-Source-LLMs-Using-Maliciously-Crafted-Prompts.pdf NIST AI Risk Management Framework (AI RMF) https://www.nist.gov/itl/ai-risk-management-framework NIST AI RMF Playbook https://www.nist.gov/itl/ai-risk-management-framework/nist-ai-rmf-playbook MITRE AI Risk Database (with Robust Intelligence) https://www.mitre.org/news-insights/news-release/mitre-and-robust-intelligence-tackle-ai-supply-chain-risks MITRE’s SAFE-AI Framework https://atlas.mitre.org/pdf-files/SAFEAI_Full_Report.pdf Cloud Security Alliance – AI Model Risk Management Framework https://cloudsecurityalliance.org/artifacts/ai-model-risk-management-framework
- Azure Integrated HSM: New Chapter&Shift from Centralized Clusters to Embedded Silicon-to-Cloud TrustAzure Integrated HSM marks a major shift in how cryptographic keys are handled—moving from centralized clusters… to local, tamper‑resistant modules embedded directly in virtual machines. This new model brings cryptographic assurance closer to the workload, reducing latency, increasing throughput, and redefining what’s possible for secure applications in the cloud. Before diving into this innovation, let’s take a step back. Microsoft’s journey with HSMs in Azure spans nearly a decade, evolving through multiple architectures, vendors, and compliance models. From shared services to dedicated clusters, from appliance‑like deployments to embedded chips, each milestone reflects a distinct response to enterprise needs and regulatory expectations. Let’s walk through that progression — not as a single path, but as a layered portfolio that continues to expand. Azure Key Vault Premium, with nCipher nShield Around 2015, Microsoft made Azure Key Vault generally available, and soon after introduced the Premium tier, which integrated nCipher nShield HSMs (previously part of Thales, later acquired by Entrust). This was the first time customers could anchor their most sensitive cryptographic material in FIPS 140‑2 Level 2 validated hardware within Azure. Azure Key Vault Premium is delivered as a fully managed PaaS service, with HSMs deployed and operated by Microsoft in the backend. The service is redundant and highly available, with cryptographic operations exposed through Azure APIs while the underlying HSM infrastructure remains abstracted and secure. This enabled two principal cornerstone scenarios. Based on the Customer Encryption Key (CEK) model, customers could generate and manage encryption keys directly in Azure, always protected by HSMs in the backend. Going further with the Bring Your Own Key (BYOK) model, organizations could generate keys in their own on‑premises HSMs and then securely import and manage them into Azure Key Vault–backed HSMs. These capabilities were rapidly adopted across Microsoft’s second-party services. For example, they underpin the master key management for Azure RMS, later rebranded as Azure Information Protection, and now part of Microsoft Purview Information Protection. These HSM-backed keys can protect the most sensitive data if customers choose to implement the BYOK model through Sensitivity Labels, applying encryption and strict usage controls to protect highly confidential information. Other services like Service Encryption with Customer Key allow customers to encrypt all their data at rest in Microsoft 365 using their own keys, via Data Encryption Policies. This applies to data stored in Exchange, SharePoint, OneDrive, Teams, Copilot, and Purview. This approach also applies to Power Platform, where customer-managed keys can encrypt data stored in Microsoft Dataverse, which underpins services like Power Apps and Power Automate. Beyond productivity services, Key Vault Premium became a building block in hybrid customer architectures: protecting SQL Server Transparent Data Encryption (TDE) keys, storing keys for Azure Storage encryption or Azure Disk Encryption (SSE, ADE, DES), securing SAP workloads running on Azure, or managing TLS certificates for large‑scale web applications. It also supports custom application development and integrations, where cryptographic operations must be anchored in certified hardware — whether for signing, encryption, decryption, or secure key lifecycle management. Around 2020, Azure Key Vault Premium benefit from a shift away from the legacy nCipher‑specific BYOK process. Initially, BYOK in Azure was tightly coupled to nCipher tooling, which limited customers to a single vendor. As the HSM market evolved and customers demanded more flexibility, Microsoft introduced a multi‑vendor BYOK model. This allowed organizations to import keys from a broader set of providers, including Entrust, Thales, and Utimaco, while still ensuring that the keys never left the protection of FIPS‑validated HSMs. This change was significant: it gave customers freedom of choice, reduced dependency on a single vendor, and aligned Azure with the diverse HSM estates that enterprises already operated on‑premises. Azure Key Vault Premium remains a cornerstone of Azure’s data protection offerings. It’s widely used for managing keys, secrets (passwords, connection strings), and certificates. Around February 2024 then with a latest firmware update in April 2025, Microsoft and Marvel has announced the modernization of the Key Vault HSM backend to meet newer standards: Azure’s HSM pool has been updated with Marvell LiquidSecurity adapters that achieved FIPS 140-3 Level 3 certification. This means Key Vault’s underpinnings are being refreshed to the latest security level, though the service interface for customers remains the same. [A tip for Tech guys: you can check the HSM backend provider by looking at the FIPS level in the "hsmPlatform" key attribute]. Key Vault Premium continues to be the go-to solution for many scenarios where a fully managed, cloud-integrated key manager with a shared HSM protection is sufficient. Azure Dedicated HSM, with SafeNet Luna In 2018, Microsoft introduced Azure Dedicated HSM, built on SafeNet Luna hardware (originally Gemalto, later part of Thales). These devices were validated to FIPS 140‑2 Level 3, offering stronger tamper resistance and compliance guarantees. This service provided physically isolated HSM appliances, deployed as single-tenant instances within a customer’s virtual network. By default, these HSMs were non-redundant, unless customers explicitly provisioned multiple units across regions. Each HSM was connected to a private subnet, and the customer retained full administrative control over provisioning, partitioning, and policy enforcement. Unlike Key Vault, using a Dedicated HSM meant the customer had to manage a lot more: HSM user management, key backup (if needed), high availability setup, and any client access configuration. Dedicated HSM was particularly attractive to regulated industries such as finance, healthcare, and government, where compliance frameworks demanded not only FIPS‑validated hardware but also the ability to define their own cryptographic domains and audit processes. Over time, however, Microsoft evolved its HSM portfolio toward more cloud‑native and scalable services. Azure Dedicated HSM is now being retired: Microsoft announced that no new customer onboardings are accepted as of August 2025, and that full support for existing customers will continue until July 31, 2028. Customers are encouraged to plan their transition, as Azure Cloud HSM will succeed Dedicated HSM. Azure Key Vault Managed HSM, with Marvell LiquidSecurity By 2020, it was evident that Azure Key Vault (with shared HSMs) and Dedicated HSM (with single-tenant appliances) represented two ends of a spectrum, and customers wanted something in between: the isolation of a dedicated HSM and the ease-of-use of a managed cloud service. In 2021, Microsoft launched Azure Key Vault Managed HSM, a fully managed, highly available service built on Marvell LiquidSecurity adapters, validated to FIPS 140‑3 Level 3. The key difference with Azure Key Vault Premium lies in the architecture and assurance model. While AKV Premium uses a shared pool of HSMs per Azure geography, organized into region-specific cryptographic domains based on nShield technology — which enforces key isolation through its Security World architecture — Managed HSM provides dedicated HSM instances per customer, ensuring stronger isolation. Also delivered as a PaaS service, it is redundant by design, with built‑in clustering and high availability across availability zones; and fully managed in terms of provisioning, configuration, patching, and maintenance. Managed HSM consists of a cluster of multiple HSM partitions, each based on a separate customer-specific security domain that cryptographically isolates every tenant. Managed HSM supports the same use cases as AKV Premium — CEK, BYOK for Azure RMS or SEwCK, database encryption keys, or any custom integrations — but with higher assurance, stronger isolation, and FIPS 140‑3 Level 3 compliance. Azure Payment HSM, with Thales payShield 10K Introduced in 2022, Azure Payment HSM is a bare-metal, single-tenant service designed specifically for regulated payment workloads. Built on Thales payShield 10K hardware, it meets stringent compliance standards including FIPS 140-2 Level 3 and PCI HSM v3. Whereas Azure Dedicated HSM was built for general-purpose cryptographic workloads (PKI, TLS, custom apps), Payment HSM is purpose-built for financial institutions and payment processors, supporting specialized operations like PIN block encryption, EMV credentialing, and 3D Secure authentication. The service offers low-latency, high-throughput cryptographic operations in a PCI-compliant cloud environment. Customers retain full administrative control and can scale performance from 60 to 2500 CPS, deploying HSMs in high-availability pairs across supported Azure regions. Azure Cloud HSM, with Marvell LiquidSecurity In 2025, Microsoft introduced Azure Cloud HSM, also based on Marvell LiquidSecurity, as a single‑tenant, cloud‑based HSM cluster. These clusters offer a private connectivity and are validated to FIPS 140‑3 Level 3, ensuring the highest level of assurance for cloud‑based HSM services. Azure Cloud HSM is now the recommended successor to Azure Dedicated HSM and gives customers direct administrative authority over their HSMs, while Microsoft handles availability, patching, and maintenance. It is particularly relevant for certificate authorities, payment processors, and organizations that need to operate their own cryptographic infrastructure in the cloud but do not want the burden of managing physical hardware. It combines sovereignty and isolation with the elasticity of cloud operations, making it easier for customers to migrate sensitive workloads without sacrificing control. A single Marvell LiquidSecurity2 adapter can manage up to 100,000 key pairs and perform over one million cryptographic operations per second, making it ideal for high-throughput workloads such as document signing, TLS offloading, and PKI operations. In contrast to Azure Dedicated HSM, Azure Cloud HSM simplifies deployment and management by offering fast provisioning, built-in redundancy, and centralized operations handled by Microsoft. Customers retain full control over their keys while benefiting from secure connectivity via private links and automatic high availability across zones — without the need to manually configure clustering or failover. Azure Integrated HSM, with Microsoft Custom Chips In 2025, Microsoft finally unveiled Azure Integrated HSM, a new paradigm, shifting from a shared cryptographic infrastructure to dedicated, hardware-backed modules integrated at the VM level: custom Microsoft‑designed HSM chips are embedded directly into the host servers of AMD v7 virtual machines. These chips are validated to FIPS 140‑3 Level 3, ensuring that even this distributed model maintains the highest compliance standards. This innovation allows cryptographic operations to be performed locally, within the VM boundary. Keys are cached securely, hardware acceleration is provided for encryption, decryption, signing, and verification, and access is controlled through an oracle‑style model that ensures keys never leave the secure boundary. The result is a dramatic reduction in latency and a significant increase in throughput, while still maintaining compliance. This model is particularly well suited for TLS termination at scale, high‑frequency trading platforms, blockchain validation nodes, and large‑scale digital signing services, where both performance and assurance are critical. Entered public preview in September 2025, Trusted Launch must be enabled to use the feature, and Linux support is expected soon. Microsoft confirmed that Integrated HSM will be deployed across all new Azure servers, making it a foundational component of future infrastructure. Azure Integrated HSM also complements Azure Confidential Computing, allowing workloads to benefit from both in-use data protection through hardware-based enclaves and key protection via local HSM modules. This combination ensures that neither sensitive data nor cryptographic keys ever leave a secure hardware boundary — ideal for high-assurance applications. A Dynamic Vendor Landscape The vendor story behind these services is almost as interesting as the technology itself. Thales acquired nCipher in 2008, only to divest it in 2019 during its acquisition of Gemalto, under pressure from competition authorities. The buyer was Entrust, which suddenly found itself owning one of the most established HSM product lines. Meanwhile, Gemalto’s SafeNet Luna became part of Thales — which would also launch the Thales payShield 10K in 2019, leading PCI-certified payment HSM — and Marvell emerged as a new force with its LiquidSecurity line, optimized for cloud-scale deployments. Microsoft has navigated these shifts pragmatically, adapting its services and partnerships to ensure continuity for customers while embracing the best available hardware. Looking back, it is almost amusing to see how vendor mergers, acquisitions, and divestitures reshaped the HSM market, while Microsoft’s offerings evolved in lockstep to give customers a consistent path forward. Comparative Perspective Looking back at the evolution of Microsoft’s HSM integrations and services, a clear trajectory emerges: from the early days of Azure Key Vault Premium backed by certified HSMs (still active), completed by Azure Key Vault Managed HSM with higher compliance levels, through the Azure Dedicated HSM offering, replaced by the more cloud‑native Azure Cloud HSM, and finally to the innovative Azure Integrated HSM embedded directly in virtual machines. Each step reflects a balance between control, management, compliance, and performance, while also adapting to the vendor landscape and regulatory expectations. Service Hardware Introduced FIPS Level Model / Isolation Current Status / Notes Azure Key Vault Premium nCipher nShield (Thales → Entrust) Then Marvell LiquidSecurity 2015 FIPS 140‑2 Level 2 > Level 3 Shared per region, PaaS, HSM-backed Active; standard service; supports CEK and BYOK; multi-vendor BYOK since ~2020 Azure Dedicated HSM SafeNet Luna (Gemalto → Thales) 2018 FIPS 140‑2 Level 3 Dedicated appliance, single-tenant, VNet Retiring; no new onboardings; support until July 31, 2028; succeeded by Azure Cloud HSM Azure Key Vault Managed HSM Marvell LiquidSecurity 2021 FIPS 140‑3 Level 3 Dedicated cluster per customer, PaaS Active; redundant, isolated, fully managed; stronger compliance than Premium Azure Payment HSM Thales payShield 10K 2022 FIPS 140-2 Level 3 Bare-metal, single-tenant, full customer control, PCI-compliant Active. Purpose-built for payment workloads. Azure Cloud HSM Marvell LiquidSecurity 2025 FIPS 140‑3 Level 3 Single-tenant cluster, customer-administered Active; successor to Dedicated HSM; fast provisioning, built-in HA, private connectivity Azure Integrated HSM Microsoft custom chips 2025 FIPS 140‑3 Level 3 Embedded in VM host, local operations Active (preview/rollout); ultra-low latency, ideal for high-performance workloads Microsoft’s strategy shows an understanding that different customers have different requirements on the spectrum of control vs convenience. So Azure didn’t take a one-size-fits-all approach; it built a portfolio: - Use Azure Key Vault Premium if you want simplicity and can tolerate multi-tenancy. - Use Azure Key Vault Managed HSM if you need sole ownership of keys but want a turnkey service. - Use Azure Payment HSM if you operate regulated payment workloads and require PCI-certified hardware. - Use Azure Cloud HSM if you need sole ownership and direct access for legacy apps. - Use Azure Integrated HSM if you need ultra-low latency and per-VM key isolation, for the highest assurance in real-time. Beyond the HSM: A Silicon-to-Cloud Security Architecture by Design Microsoft’s HSM evolution is part of a broader strategy to embed security at every layer of the cloud infrastructure — from silicon to services. This vision, often referred to as “Silicon-to-Cloud”, includes innovations like Azure Boost, Caliptra, Confidential Computing, and now Azure Integrated HSM. Azure Confidential Computing plays a critical role in this architecture. As mentioned, by combining Trusted Execution Environments (TEEs) with Integrated HSM, Azure enables workloads to be protected at every stage — at rest, in transit, and in use — with cryptographic keys and sensitive data confined to verified hardware enclaves. This layered approach reinforces zero-trust principles and supports compliance in regulated industries. With Azure Integrated HSM installed directly on every new server, Microsoft is redefining how cryptographic assurance is delivered — not as a remote service, but as a native hardware capability embedded in the compute fabric itself. This marks a shift from centralized HSM clusters to distributed, silicon-level security, enabling ultra-low latency, high throughput, and strong isolation for modern cloud workloads. Resources To go a bit further, I invite you to check out the following articles and take a look at the related documentation. Protecting Azure Infrastructure from silicon to systems | Microsoft Azure Blog by Mark Russinovich, Chief Technology Officer, Deputy Chief Information Security Officer, and Technical Fellow, Microsoft Azure, Omar Khan, Vice President, Azure Infrastructure Marketing, and Bryan Kelly, Hardware Security Architect, Microsoft Azure Microsoft Azure Introduces Azure Integrated HSM: A Key Cache for Virtual Machines | Microsoft Community Hub by Simran Parkhe Securing Azure infrastructure with silicon innovation | Microsoft Community Hub by Mark Russinovich, Chief Technology Officer, Deputy Chief Information Security Officer, and Technical Fellow, Microsoft Azure About the Author I'm Samuel Gaston-Raoul, Partner Solution Architect at Microsoft, working across the EMEA region with the diverse ecosystem of Microsoft partners—including System Integrators (SIs) and strategic advisory firms, Independent Software Vendors (ISVs) / Software Development Companies (SDCs), and Startups. I engage with our partners to build, scale, and innovate securely on Microsoft Cloud and Microsoft Security platforms. With a strong focus on cloud and cybersecurity, I help shape strategic offerings and guide the development of security practices—ensuring alignment with market needs, emerging challenges, and Microsoft’s product roadmap. I also engage closely with our product and engineering teams to foster early technical dialogue and drive innovation through collaborative design. Whether through architecture workshops, technical enablement, or public speaking engagements, I aim to evangelize Microsoft’s security vision while co-creating solutions that meet the evolving demands of the AI and cybersecurity era.
- Azure AD PIM token lifetimesDoes anyone know if Azure AD PIM has any impact on token lifetimes? I know an access token remains valid for 1 hour whereas a refresh token can have long life. Does this mean if user activates their role for only 30mins, they will continue to have privileged access for at least one hour unless user explicitly logs-out of the session.4.3KViews2likes3Comments
- Security Copilot Agents: The New Era of AI, Driven Cyber DefenseWith increasing cyber threats, security teams require intelligent agents that adapt and operate throughout the security stack, not just automation. Key statistics from our Microsoft Digital Defense Report 2024 which highlights this concerning trend of Cybersecurity threats: Over 600 million cyberattacks per day targeting Microsoft customers 2.75x increase in ransomware attacks year-over-year 400% surge in tech scams since 2022 Growing collaboration between cybercriminals and nation-state actors In my previous blogs, I explored how AI agents are transforming security operations in Microsoft Defender XDR, Intune, and Entra: Phishing Triage Agent in Defender XDR: Say Goodbye to False Positives and Analyst Fatigue Intune AI Agent: Instant Threat Defense, Invisible Protection Conditional Access Optimization Agent in Microsoft Entra Security Copilot Today, I’ll discuss how Security Copilot, Copilot for Azure in Azure, Defender for Cloud, and Security Copilot Agents in Microsoft Purview use AI to transform security, compliance, and efficiency across the Microsoft ecosystem. What Are Security Copilot Agents? Security Copilot Agents are modular, AI-driven assistants embedded in Microsoft’s security platforms. They automate, high-volume repetitive tasks, deliver actionable insights, and streamline incident responses. By leveraging large language models (LLMs), Microsoft’s global threat intelligence, and your organization’s data, these agents empower security teams to work smarter and faster. Microsoft Security Copilot agents overview Agents are available in both standalone and embedded experiences and can be discovered and configured directly within product portals like Defender, Sentinel, Entra, Intune, and Purview. Why Security Copilot Agents Matter Security Copilot Agents represent a paradigm shift in cyber defense: Automation at Scale: They handle high-volume repetitive tasks, freeing up human expertise for strategic initiatives. Adaptive Intelligence: Agents learn from feedback, adapt to workflows, and operate securely within Microsoft’s Zero Trust framework. Operational Efficiency: By reducing manual workloads, agents accelerate response, prioritize risks, and strengthen security posture. Microsoft Security Copilot Frequently Asked Questions Security Copilot Agents in Azure and Defender for Cloud Azure and Defender for Cloud now feature embedded Security Copilot and Copilot for Azure that help security professionals analyze, summarize, remediate, and delegate recommendations using natural language prompts. This integration streamlines security management by: Risk Exploration: Agents help admins identify misconfigured resources and focus on those posing critical risks, using natural language queries. Accelerated Remediation: Agents generate remediation scripts and automate pull requests, enabling rapid fixes for vulnerabilities. Noise Reduction: By filtering through alerts and recommendations, agents help teams focus on the most impactful remediations. Unified Experience: Security Copilot and Copilot for Azure work together to provide context, explain recommendations, and guide implementation steps, all within the Defender for Cloud portal. Microsoft Security Copilot in Defender for Cloud Security Copilot Agents in Microsoft Purview Microsoft Purview leverages Security Copilot agents to automate and scale Data Loss Prevention (DLP) and Insider Risk Management workflows. Here are more details: Alert Triage Agent (DLP): Evaluates alerts based on sensitivity, exfiltration, and policy risk, sorting them into actionable categories. Alert Triage Agent (Insider Risk): Assesses user, file, and activity risk, prioritizing alerts for investigation. Managed Alert Queue: Agents sift out high-risk activities from lower-risk noise, improving response time and team efficiency. Comprehensive Explanations: Agents provide clear logic behind alert categorization, supporting transparency and compliance. Deployment: Enabling Security Copilot can be done in: Azure portal https://portal.azure.com Security Copilot portal https://securitycopilot.microsoft.com. Security Copilot requires per-seat licenses for human users, while all agent operations are billed by Security Compute Units (SCUs) on a pay-as-you-go basis. Agents do not need separate per-seat licenses; their costs depend solely on SCU consumption, and they typically run under a service or managed identity in the Copilot environment. Security Copilot Agent Responsible AI FAQ Security Copilot Agents: Unified Across the Microsoft Security Ecosystem Security Copilot Agents automate intelligence and security orchestration across Microsoft’s ecosystem, including Defender, Sentinel, Entra, Intune, Azure, Purview, Threat Intelligence, and Office. Their unified design enables consistent protection, swift responses, and scalable automation for security teams. Operating across multiple platforms, these agents provide comprehensive coverage and efficient threat response. End-to-End Visibility: Agents correlate signals across domains, providing context, rich insights and automating common workflows. Custom Agent Creation: Teams can build custom agents using no-code tools, tailoring automation to their unique environments. Marketplace Integration: The new Security Store allows organizations to browse, deploy, and manage agents alongside conventional security tools, streamlining procurement and governance. Intune AI Agents: Device and Endpoint Management Intune AI Agents automate device compliance and endpoint security. They monitor configuration drift, remediate vulnerabilities, and enforce security baselines across managed devices. By correlating device signals with threat intelligence, these agents proactively identify risks and recommend mitigation actions, reducing manual workload and accelerating incident response. Defender for Cloud AI Agents: Threat Detection and Response Defender for Cloud AI Agents continuously analyze cloud workloads, network traffic, and user behavior to detect threats and suspicious activities. They automate alert triage, escalate high-risk events, and coordinate remediation actions across hybrid environments. Integration with other Copilot Agents ensures unified protection and rapid containment of cloud-based threats. Conditional Access Optimization Agent: Policy Automation The Conditional Access Optimization Agent evaluates authentication patterns, risk signals, and user activity to recommend and enforce adaptive access policies. It automates policy updates based on real-time threat intelligence, ensuring that only authorized users access sensitive resources while minimizing friction for legitimate users. Azure AI Agents: Cloud Security and Automation Azure AI Agents provide automated monitoring, configuration validation, and vulnerability management across cloud resources. They integrate with Defender for Cloud and Sentinel, enabling cross-platform correlation of security events and orchestration of incident response workflows. These agents help maintain compliance, optimize resource usage, and enforce best practices. Purview AI Agents: Compliance and Data Protection Purview AI Agents automate data classification, information protection, and compliance management for AI-powered applications and Copilot experiences. They enforce retention policies, flag sensitive data handling, and ensure regulatory compliance across organizational data assets. Their integration supports transparent security controls and audit-ready reporting. Phishing Triage Defender for Office AI Agents: Email Threat Automation Defender for Office AI Agents specialize in identifying, categorizing, and responding to phishing attempts. They analyze email metadata, attachments, and user interactions to detect malicious campaigns, automate alerting, and initiate containment actions. By streamlining phishing triage, these agents reduce investigation times and enhance protection against targeted attacks. Threat Intelligence Briefing Agent: Contextual Security Insights The Threat Intelligence Briefing Agent aggregates global threat intelligence, correlates it with local signals, and delivers actionable briefings to security teams. It highlights emerging risks, prioritizes vulnerabilities, and recommends remediation based on organizational context. This agent empowers teams with timely, relevant insights to anticipate and counter evolving threats. Marketplace Integration and Custom Agent Creation Organizations can leverage the Security Store to discover, deploy, and manage agents tailored to their specific needs. No-code tools facilitate custom agent creation, enabling rapid automation of unique workflows and seamless integration with existing security infrastructure. Getting Started To deploy Security Copilot Agents across the enterprise, make sure to Check Licensing: Ensure you have the required subscriptions and SCUs provisioned. Enable Agents: Use product portals to activate agents and configure settings. Integrate Across Products: Link agents for enhanced threat detection, compliance, and automated response. Monitor and Optimize: Use dashboards and reports to track effectiveness and refine policies. About the Author: Hi! Jacques “Jack” here, Microsoft Technical Trainer. As a technical trainer, I’ve seen firsthand how Security Copilot Agents accelerate secure modernization and empower teams to stay ahead of threats. Whether you’re optimizing identity protection, automating phishing triage, or streamlining endpoint remediation, these agents are your AI, powered allies in building a resilient security posture. #MicrosoftLearn #SkilledByMTT #MTTBloggingGroup