Introducing scheduled antivirus scans on Microsoft Defender Linux
Security teams rely on scheduled scans to ensure consistent coverage across devices, detect dormant or missed threats, and meet compliance requirements. However, managing scans on Linux has traditionally required custom scripts and cron-based setups, which can be hard to scale and maintain. That’s why we’re excited to introduce centrally managed scheduled antivirus scans for Linux in Microsoft Defender. With this release, we are bringing built-in, flexible scheduling capabilities directly into Defender - making it easier to manage and standardize scan behavior across Linux environments. What’s new With this capability, customers can now configure scheduled antivirus scans on Linux using security settings management policies in the Microsoft Defender portal for centralized policy enforcement or local Managed JSON configuration that can be deployed via configuration management tools like ansible, puppet and chef. The feature supports a flexible set of scheduling options, including hourly quick scans (interval-based scheduling), daily quick scans at a defined time, and weekly scans with configurable scan type (quick or full). In addition, customers can control how scans run with advanced options such as: Running scans only when the device is idle Reducing CPU impact using low CPU priority Checking for definition updates before scanning Randomizing scans start times Ignoring exclusions during scheduled scans These capabilities allow security teams to balance coverage, performance, and operational needs across large Linux environments. Why this matters From a security perspective, scheduled scans play a critical role in detecting dormant threats, missed detections, and malicious artifacts that may not be caught through real-time protection alone. Without consistent and centrally enforced scheduling, these gaps can increase risk across the environment. With this release, scheduled scans are now: Centrally managed through Defender policies Consistently enforced across devices Aligned with security best practices for regular scanning Integrated into the broader Defender security posture This helps organizations strengthen their overall security posture while reducing operational complexity. Get started To get started, ensure devices are running agent version 101.26032.0000 or later (production ring), and configure scheduled scans using managed JSON or Defender portal policies. Learn more Learn more about how to schedule antivirus scans on Linux To learn more about endpoint protection with Microsoft Defender, check out our website. To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.
Reduce unnecessary internet exposure with Microsoft Defender
In today’s threat landscape, internet exposure, i.e. devices that allow inbound connectivity from the public internet, continues to be a major vector for initial access and compromise. Devices that are exposed to the public internet can significantly increase an organization’s attack surface, making them prime targets for initial access, exploitation, and lateral movement. However, not all internet-facing devices represent a security issue. Many are intentionally exposed to support business-critical scenarios such as hosting web applications, enabling remote access, or supporting communication services. The challenge for security teams is not just detecting internet-facing devices, but understanding why a device is exposed, whether that exposure is expected, and what action should be taken. That’s why we’re introducing a new security recommendation in Microsoft Defender that helps organizations identify, review, and reduce unnecessary internet exposure across their environment. Understand your internet-facing exposure This recommendation focuses specifically on devices that are accessible from the public internet, meaning they can receive inbound connections initiated from external sources, not devices that only use the internet for outbound communication. Externally reachable assets are often the first point of entry for attackers, making this a critical signal for security prioritization. Microsoft Defender identifies internet-facing devices based on signals that indicate external inbound reachability, including: External scan telemetry identifying devices reachable from the public internet Network telemetry showing inbound connections from external sources By correlating these signals, Defender surfaces devices that are externally reachable. Introducing internet-facing exposure assessment A new recommendation in Microsoft Defender provides a centralized view of devices that are externally reachable from the public internet, helping you understand and manage exposure across your environment. This assessment categorizes devices based on their exposure state: Exposed devices: Devices that are reachable from the public internet and require review Compliant devices: Devices that are not externally reachable, or where the internet exposure has been explicitly validated and accepted by the organization’s security team as intended Not applicable devices: Devices that do not exhibit inbound internet exposure From the recommendation view, you can: Drill down into exposed devices and understand why they are reachable Review context such as exposed services and connectivity Explore device-level details to support investigation Track exposure posture across your environment over time Take action on your internet exposure To access this recommendation in the Defender portal, navigate to Exposure management → Recommendations → Devices → Misconfigurations. Once Defender identifies internet-facing devices, it provides the context needed to review and take action. Your action plan 1. Assess your exposure Review the recommendation to understand which devices in your environment are externally reachable from the public internet and why they were classified as internet-facing. 2. Validate whether exposure is required Determine if the inbound connectivity is expected for each device. Confirm business need and ownership before taking action. 3. Prioritize high-risk assets Focus on critical servers or sensitive environments that are exposed to the internet, as they present the highest risk for initial access. 4. Reduce unnecessary exposure Restrict or remove inbound connectivity where it is not required by closing exposed ports, removing public access, or moving services behind controlled access layers. 5. Track and maintain posture over time Continuously monitor internet-facing devices to ensure unnecessary exposure is reduced and new exposure is validated as environments evolve. FAQ 1. Which devices are currently supported? This recommendation applies to supported Windows client and Windows Server devices. Supported versions include Windows 10, version 1607 and earlier; Windows 10, version 1809 and later; and Windows 11. 2. Why might there be differences between this recommendation and the Internet-facing filter in device inventory? This recommendation reflects devices observed as internet-facing during the recommendation assessment window. Device exposure can change over time, and different Microsoft Defender experiences may refresh at different times. As a result, temporary differences may occur between this recommendation and the Internet-facing filter in device inventory. For the most current device-level view, use the Internet-facing filter in device inventory. If a device was recently remediated or its exposure recently changed, allow time for the recommendation status to refresh. 3. Could regular employee laptops or personal devices appear as internet-facing? This recommendation evaluates supported devices onboarded to Microsoft Defender for Endpoint and focuses specifically on inbound internet reachability. Typical internet usage, such as web browsing, generates outbound traffic and does not by itself classify a device as internet-facing. Devices are identified as internet-facing only when they are externally reachable from the public internet. As a result: Personal devices that are not onboarded to Microsoft Defender for Endpoint are not included in this assessment. Corporate laptops may appear as internet-facing if they are directly reachable from the internet, which may indicate an unintended network exposure or configuration issue. Learn more For additional guidance on investigating and managing internet-facing devices, see: Learn how Defender identifies and maps externally reachable devices across your environment Discovering internet-facing devices using Microsoft Defender Learn how to review and investigate internet-facing device exposure Investigate devices in Microsoft Defender Learn more about Microsoft Secure Score for Devices in Microsoft Defender To learn more about endpoint protection with Microsoft Defender, check out our website. To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.
Elevate your telemetry using custom data collection in Microsoft Defender
At Ignite in November, we announced that Microsoft Defender is now the only endpoint protection solution that allows data-hungry security teams to meet specific telemetry needs by optimizing their data collection right within the Defender portal, without the need to rely on fragmented and siloed solutions. Since then, we've heard from customers that this tool has been a game changer, enabling them to hunt through new data types as well as richer data on events already reported. The release of custom data collection was a key milestone in our ongoing journey to make Defender easy to manage and customize. Security teams have been asking for guidance and examples of how to get the most out of the tool, so today we're sharing how some organizations can use custom data collection and dynamic tagging to detect command and control (C2) communications, giving defenders elevated visibility and deeper telemetry into attacker activity across the environment. See the data you want to see Defender's default telemetry is tuned to balance performance and signal-to-noise across millions of devices, so it focuses on the events most useful for high-fidelity detection at fleet scale, but many organizations want richer, more granular signals for deeper hunting, compliance, or auditing purposes. Custom data collection lets you go beyond what Defender already captures without ever leaving the Defender portal. Easily build custom collection rules based on your organization’s specific needs using natural language; no PhD required! It includes several highly requested data types, including AMSI for hunting over script content, and Kerberos for hunting auth-based and network attacks. This truly integrated custom data offering is possible thanks to Microsoft’s platform approach, as the additional telemetry can be collected and analyzed via Defender and stored via Microsoft Sentinel. It puts you in complete control of any customized, add-on data, including exactly which data types are collected and how long they are stored. No other security solution has fully integrated and customizable telemetry collection and analysis. Example custom telemetry scenario: detecting C2 communications Many organizations have a set of assets that require special attention, like internet-facing servers, domain controllers, and other high-value endpoints where deeper telemetry can make the difference between catching an intrusion early and discovering it after the damage is done. Imagine your organization has received threat intelligence on attacks using stealthy C2 frameworks: HTTPS beacons with jittered intervals, DNS-based data exchange, and persistence via scheduled tasks and registry modifications. You want richer visibility into those internet-facing servers and high-value endpoints so you can hunt for these patterns proactively, instead of reconstructing them after the fact. Dynamic tags scope these high-value devices into a targeted group, and custom data collection captures the extra process, network, and registry events from them, giving analysts the telemetry they need to hunt for beaconing, suspicious DNS patterns, and persistence before attackers establish a foothold. To detect C2 communications using dynamic tagging, follow these steps: Step 1: Tag your devices Custom Data Collection rules are scoped to dynamic tags; once set, those tags are automatically applied and removed based on conditions you define. Configure them in Settings > Microsoft Defender XDR > Asset Rule Management. Tag Rule name Conditions Tag to apply Internet-facing servers InternetFacing-Servers Internet facing = true AND OS platform equals Windows Server 2022 C2-Watchlist Devices under active investigation HighSev-Investigation Manual tag equals UnderInvestigation HighSev-Verbose Bringing manual tags into the dynamic model Custom data collection is built around dynamic tags by design: one leading, unified tagging experience that's more flexible and customizable. Dynamic tags can be driven by device properties, group membership, OS, or by existing manual tags, so anything your team already tags manually flows naturally into custom data collection through a simple Asset Rule Management rule, exactly as Tag 2 above does. In this example, analysts manually tag a device UnderInvestigation during incident response. The dynamic rule picks up that manual tag and applies HighSev-Verbose, which custom data collection rules can target. The analyst doesn't need to know about dynamic tags they tag the device the way they always have, and custom data collection activates automatically. Step 2: Build your collection rules Navigate to Settings > Endpoints > Rules > Custom Data Collection. Select your Microsoft Sentinel workspace in the top-right corner. Before creating rules, confirm you meet every prerequisite in the custom data collection documentation , in particular, your tenant must be onboarded to the Unified Security Operations Platform (USOP). Rule 1: Outbound network connections from high-risk processes Capture connections from processes commonly abused by C2 frameworks living-off-the-land binaries and scripting engines. Setting Value Rule name C2-OutboundConnections Table DeviceCustomNetworkEvents Action Connection Success Condition InitiatingProcessFileName Equals: powershell.exe, rundll32.exe, regsvr32.exe, mshta.exe, certutil.exe, msiexec.exe Scope Devices tagged C2-Watchlist Rule 2: DNS query activity Many C2 frameworks use DNS for beaconing or data exchange. Default telemetry captures limited DNS data. This rule collects all DNS queries from monitored devices. Setting Value Rule name C2-DNSActivity Table DeviceCustomNetworkEvents Action Connection Success Condition RemotePort equals 53 Scope Devices tagged C2-Watchlist Rule 3: Persistence mechanisms C2 implants establish persistence via scheduled tasks, registry run keys, or services. Capture process creation events for common persistence tools. Setting Value Rule name C2-Persistence Table DeviceCustomProcessEvents Action Process Created Condition FileName in (schtasks.exe, reg.exe, sc.exe, at.exe) Scope Devices tagged C2-Watchlist Rule 4: Full process and script telemetry during investigations When a device gets the HighSev-Verbose tag, collect everything. Setting Value Rule name HighSev-AllProcesses Table DeviceCustomProcessEvents Action Process Created Condition Broad (all process creation events) Scope Devices tagged HighSev-Verbose Setting Value Rule name HighSev-ScriptCapture Table DeviceCustomScriptEvents Action Script execution Condition Broad (all script events) – add a condition which is always true such as FileName not equals “” Scope Devices tagged HighSev-Verbose Collection profiles summary Tag Rules active What gets collected Use case C2-Watch list OutboundConnections, DNSActivity, Persistence Network connections from, DNS queries, persistence tool usage, DLL sideloading Persistent C2 monitoring HighSev-Verbose AllProcesses, ScriptCapture Every process creation, all script execution Full-depth incident response Important: when you remove the HighSev-Verbose tag after closing an incident, collection automatically drops back to baseline, no manual rule cleanup needed. This is what makes verbose collection safe to leave configured: it's only active while the tag is. Step 3: Hunt Rules deploy within 20 minutes to an hour. Query the data in AH directly. Detect beaconing patterns processes making regular-interval outbound connections: Find DNS queries to high-entropy domains (potential DGA): Spot persistence being established: Leverage the telemetry from your new collection rule into a Custom Detection so high-value findings raise alerts automatically, instead of waiting for the next manual hunt. Custom data collection effectively extends your endpoint protection into a targeted, general-purpose log collector, one that's now ready to serve advanced hunting, custom detections, and auditing or regulatory use cases, while default fleet-wide telemetry stays tuned for performance and signal-to-noise. By combining dynamic tagging with purpose-built collection rules, your highest-risk devices are always streaming the signals that matter most, ready for detection and investigation before and during an incident. Learn more To learn more about endpoint protection with Microsoft Defender, check out our website. To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity. To learn more about custom data collection and how to get started, see our documentation.Microsoft Defender now monitors RPC activity
Remote procedure call (RPC) is a protocol commonly abused by attackers that allows functions implemented in a separate process, and potentially on a remote machine, to be called as if they were local. Many core Windows and Active Directory capabilities are built on or make use of RPC, which makes it an attractive target. To help protect against remote RPC-based attacks, Microsoft Defender now monitors remote RPC calls, disrupts malicious activity that leverages them, and surfaces relevant telemetry in advanced hunting. RPC basics While RPC is a rich and complicated protocol, the main components that are relevant for security monitoring purposes are: Interface: A logical grouping of functionality exposed by an RPC server. Interfaces are identified by UUID. Example interfaces include Task Scheduler, Remote Registry, and the Service Control Manager, each exposing functionality related to a different Windows OS component. OpNum: Stands for Operation Number, an ordinal that denotes a specific function exposed by an RPC interface. Examples include RCreateServiceW (OpNum 12, Service Control Manager interface) and BaseRegQueryValue (OpNum 17, Remote Registry interface). Many remote attack techniques and tactics are based on RPC, for example: Lateral movement: often abuses RPC functionality for remotely creating tasks, services or invoking WMI. Credential theft: DCsync attacks, which abuse privileged compromised accounts to remotely extract credential material from Active Directory, are based on RPC functionality for directory replication. SecretsDump and similar attacks, which remotely extract SAM or LSA secrets, are based on querying a device’s registry remotely, using RPC. Privilege escalation: Multiple authentication coercion attacks abuse benign RPC interfaces to coerce servers to authenticate an attacker. Discovery: Tools such as SharpHound leverage RPC calls to enumerate users, sessions and shares. For a more comprehensive mapping of RPC interfaces to attack techniques, see work by Jonathan Johnson. RPC auditing in Defender Since RPC is so heavily used on Windows systems and in Active Directory domains, monitoring remote RPC traffic using network monitors is often expensive and infeasible. Additionally, if the underlying transport protocol is encrypted (such as SMB3), it might be impossible to observe RPC traffic. To enable efficient auditing of remote RPC activity regardless of transport-layer protection, Defender research and engineering expanded the existing RPC integration with the Windows Filtering Platform (WFP) to support OpNum-level granularity. This makes it possible to identify and audit the specific RPC function being invoked, rather than only the RPC interface. This capability is designed to help detect remote RPC-based attack techniques, where an attacker interacts with RPC interfaces exposed by a target device. For that reason, Defender focuses this monitoring on inbound remote RPC calls observed on the RPC server host. The telemetry is collected using audit-only WFP filters, which do not interfere with normal traffic, while still providing visibility into suspicious remote activity targeting the device. This approach does not require visibility into the source device. Local RPC calls, such as inter-process communication on the same device over local transport, and outbound RPC client calls are outside the scope of this monitoring mechanism. Using this capability, Defender monitors selected RPC calls, leverages the resulting telemetry to detect malicious activity, and exposes monitored calls in advanced hunting. Defender dynamically monitors selected remote operations from interfaces including, but not limited to: Remote Registry, Service Control Manager, Task Scheduler, and Windows Management Instrumentation (WMI). RPC monitoring for workstations is generally available, while server monitoring is currently in gradual rollout. RPC-based detections and disruption triggers are already available in Defender and include detections such as: Ongoing hands-on-keyboard attack via Impacket toolkit Suspicious service creation initiated remotely Indication of local security authority secrets theft Unusual RPC user and session discovery Authentication coercion attack Example Advanced Hunting queries 1. Remote registry key save events, abused for remote credential dumping. let remoteRegistryInterface = '338cd001-2244-31f1-aaaa-900038001003'; let registrySaveOpnums = dynamic([20, 31]); // BaseRegSaveKey, BaseRegSaveKeyEx DeviceEvents | where ActionType == 'InboundRemoteRpcCall' | extend AdditionalFields = parse_json(AdditionalFields) | extend RpcInterface = tostring(AdditionalFields.RpcInterfaceUuid), OpNum = toint(AdditionalFields.RpcOpNum) | where RpcInterface == remoteRegistryInterface and OpNum in(registrySaveOpnums) 2. Remote Service Creation events, could indicate lateral movement: let remoteServicesInterface = '367abb81-9844-35f1-ad32-98f038001003'; let serviceCreationOpnums = dynamic([12, 24, 44, 45, 60]); // RCreateServiceW, RCreateServiceA, RCreateServiceWOW64A, RCreateServiceWOW64W, RCreateWowService DeviceEvents | where ActionType == 'InboundRemoteRpcCall' | extend AdditionalFields = parse_json(AdditionalFields) | extend RpcInterface = tostring(AdditionalFields.RpcInterfaceUuid), OpNum = toint(AdditionalFields.RpcOpNum) | where RpcInterface == remoteServicesInterface and OpNum in(serviceCreationOpnums) 3. Session discovery events, could indicate account discovery: let srvsvcInterface = '4b324fc8-1670-01d3-1278-5a47bf6ee188'; let netrSessionEnumOpnum = 12; DeviceEvents | where ActionType == 'InboundRemoteRpcCall' | extend AdditionalFields = parse_json(AdditionalFields) | extend RpcInterface = tostring(AdditionalFields.RpcInterfaceUuid), OpNum = toint(AdditionalFields.RpcOpNum) | where RpcInterface == srvsvcInterface and OpNum == netrSessionEnumOpnum | summarize dcount(DeviceId) by AccountName, AccountDomain, AccountSid Check out the advanced hunting tab to see monitored RPC activity in your environment and stay tuned for more updates from Defender. Learn more To learn more about endpoint protection with Microsoft Defender, check out our website. To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.
How Microsoft Defender used predictive shielding to proactively disrupt a ransomware attack
Modern ransomware attacks are increasingly designed to blend in with normal IT operations, using trusted administrative tools to quietly weaken defenses and distribute malicious payloads at scale. In a recent real‑world incident, a human‑operated ransomware actor attempted to do exactly that by abusing Group Policy Objects (GPOs) to target hundreds of devices, but Microsoft Defender detected the attack and proactively hardened those devices before GPOs were deployed. The attacker’s plan The target organization, a large educational institution with more than a couple of thousand devices onboarded to Microsoft Defender, had already experienced a compromise of a domain admin account from an unmanaged device before the ransomware deployment attempt began. Because GPOs are a trusted mechanism for pushing configuration changes across devices, they present an attractive path for attackers looking to disable security tools or deploy ransomware broadly without needing to access each machine individually. This attacker’s plan involved weaponizing GPOs to: Push tampering configurations that could disable Defender protections across the environment Distribute and execute ransomware via scheduled tasks Leverage built‑in enterprise infrastructure to scale the attack This approach allowed the attacker to attempt ransomware deployment through standard administrative channels, minimizing the need for direct interaction with individual devices and increasing the potential for widespread impact. How Defender thwarted the attack First, Defender quickly detected the attack and contained the domain admin account that the attacker had compromised. Then, since the attacker had created a malicious GPO that disabled key Defender protections, a Defender tampering alert was triggered. In response, predictive shielding activated GPO hardening, temporarily pausing the propagation of new GPO policies across all MDE onboarded devices reachable from the attacker’s standpoint and achieved protection of ~85% of devices against the tampering policy before ransomware was deployed. Ten minutes later, the attacker attempted to distribute ransomware, but because GPO hardening had already been applied, GPO propagation was already disabled on the targeted devices and the attacker was unsuccessful. Defender recognized that GPO tampering is a precursor to ransomware distribution and acted preemptively. It didn’t wait for ransomware to appear; it acted on what the attacker was about to do, preventing downstream impact such as recovery costs and operational downtime. The results Zero machines were encrypted via the GPO path. Roughly 97% of devices the attacker attempted to encrypt were fully protected by Defender. A limited number of devices experienced encryption during concurrent ransomware activity over SMB; however, attack disruption successfully contained the incident and stopped further impact. 700 devices applied the predictive shielding GPO hardening policy, reflecting the attacker’s broad targeting scope, and blocking the propagation of the malicious policy set by the attacker within approximately 3 hours. Attackers are getting more sophisticated, finding ways to evade detection by abusing legitimate IT tools that organizations rely on and can’t simply turn off. Security teams can’t restrict these mechanisms without impacting daily operations. By detecting ransomware staging and predicting the attacker’s next move, Defender can apply targeted restrictions just in time, shifting from reactive response to proactive prevention, stopping only what matters when it matters while maintaining full business productivity. With average ransom demands now ranging from $2–5M, the downstream recovery and remediation savings from preventing these attacks can be massive. Learn more To learn more about this specific attack, check out the full case study: Case study: How predictive shielding in Defender stopped GPO-based ransomware before it started [microsoft.com] To learn more about endpoint protection with Microsoft Defender, check out our website. To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.Introducing selective response actions for high-value assets in Microsoft Defender
Deploying Microsoft Defender on high-value assets (HVAs) such as domain controllers, ADFS servers, and other Tier-0 systems, requires a thoughtful approach to balance strong protection with operational stability. Given the powerful response capabilities available, organizations often seek greater control over how these actions are applied in sensitive environments. Many organizations, especially those with strict privileged access management policies, also prefer to limit cloud-initiated administrative actions on Tier-0 systems to align with their security and compliance requirements. We introduced simplified onboarding in late 2025 with the release of the Defender deployment tool, and now we’re excited to announce that selective response actions for high-value assets are now available in public preview to afford security teams greater flexibility within the onboarding process. This new capability provides a more controlled and flexible approach, enabling organizations to define exactly which response actions are allowed on critical assets. Security teams can maintain operational continuity while still benefiting from the full visibility and protection of Defender. How it works Deploying Defender on high-value assets requires additional safeguards. This capability introduces a controlled onboarding experience that enforces strict boundaries from the start. Security teams can: Generate a custom onboarding package tailored specifically for Tier-0 and High-Value Assets Use the Defender deployment tool, a lightweight, dynamic tool that simplifies onboarding and removes the need for complex scripts Leverage secure key validation and package expiry, ensuring controlled and secure deployment Explicitly define which remote response actions are permitted on sensitive systems Onboard both Windows workstations and Windows Server environments This approach ensures that security controls are applied consistently and cannot be altered post-deployment, reducing the risk of misconfiguration or misuse. package settings Key benefits Selective response actions for high-value assets provide a safer and more controlled way to protect critical systems: Reduce operational risk by limiting powerful security actions on Tier-0 assets Prevent accidental or malicious disruptions caused by overprivileged or compromised accounts Align with privileged access management (PAM) policies by restricting cloud-initiated administrative actions Support compliance and regulatory requirements with stricter enforcement of security controls Maintain full Defender visibility and protection without overexposing sensitive systems Provide explicit and granular control over remote response capabilities Secure your most critical assets with confidence You can now extend Defender for Endpoint protection to your most critical Windows systems, while maintaining strict control over how those systems are accessed and managed. This capability empowers security teams to protect what matters most with confidence and precision. Learn more Learn more about how to set up selective response actions for high value assets To learn more about endpoint protection with Microsoft Defender, check out our website. To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.Assess Secure Boot status with Microsoft Defender
Understanding the Secure Boot certificate challenge Secure Boot is a foundational security feature that validates the integrity of your device's boot process, ensuring only trusted software can run during system startup. This protection has been quietly defending enterprise devices since 2012, but the original 2011 certificates that enable this trust are approaching their expiration date. When certificates expire in June 2026, devices that haven't transitioned to the new Windows UEFI CA 2023 certificates will no longer be able to receive new security protections for the early boot process. While these devices will continue to boot, they may no longer be able to receive or enforce new protections at the earliest stages of system startup. Over time, this can weaken the device’s root of trust and expose it to classes of attacks that operate before the operating system and security controls are fully loaded: Malicious or tampered boot components may no longer be reliably blocked if they are not signed with trusted certificates Devices may be unable to adopt future Secure Boot policy updates designed to mitigate newly discovered boot-level threats Attackers may attempt to leverage boot-level persistence techniques that operate below the visibility of traditional security controls As new vulnerabilities and protections are introduced, devices that are not updated will gradually fall behind in their ability to enforce trust at boot, but the challenge isn’t just knowing that this transition needs to happen, it’s understanding which devices in your fleet have successfully completed the update and which still require attention. Introducing Secure Boot 2023 certificate assessment A new recommendation in Defender allows you to ensure that devices are updated to Secure Boot 2023 certificates and boot manager, providing a centralized, at-scale view of Secure Boot certificate readiness across your environment. This assessment automatically categorizes your devices into: Exposed devices: Still trusting older Secure Boot certificates without trust for newer Secure Boot certificates Compliant devices: Successfully relying on the 2023 certificates and signed boot manager Not applicable devices: Systems where Secure Boot is disabled or not supported From the recommendation view, you can: Drill down into exposed devices and identify exactly which systems require attention Filter by OS platform and device context to prioritize remediation efforts Export device data to share with infrastructure and platform teams Track rollout progress across your organization Integrate findings into existing security posture workflows Take action on your Secure Boot readiness To access this tool in the Defender portal, navigate to Exposure Management → Recommendations → Devices → Misconfigurations. Once Defender identifies exposed devices, it provides remediation guidance. For detailed deployment guidance, including enterprise rollout strategies and validation practices, see: https://aka.ms/GetSecureBoot Your action plan Assess your exposure Navigate to the tool to understand how many devices in your environment require updates. Engage the right teams Secure Boot certificate deployment is typically owned by infrastructure and platform teams, so coordinate across your organization. Prioritize high-value assets Focus remediation efforts on critical devices and sensitive environments first. Track progress over time Monitor rollout progress and ensure coverage improves ahead of the June 2026 deadline. Learn more Visit the comprehensive Secure Boot guidance at https://aka.ms/GetSecureBoot Learn more about Microsoft Secure Score for Devices in Microsoft Defender for Endpoint To learn more about endpoint protection with Microsoft Defender, check out our website. To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.
New blog | Analyze IoT/OT device firmware with Microsoft Defender for IoT
Consider an organization that has thousands of endpoints on their network that are running 10-year old, unpatched SSH servers. Or when a critical vulnerability like log4shell is discovered, having no easy way to know which of those endpoints are exploitable. This is the situation organizations find themselves in when it comes to IoT and OT devices. This problem is so important that the US National Cybersecurity Strategy released a report in March 2023 indicating the IoT security threat as a strategic objective. Read the blog: Analyze IoT/OT device firmware with Microsoft Defender for IoT
