Safeguard
Research•

What makes endpoint security management hard, and how do you fix it?

Unknown devices, postponed patches and drifting policy cause most endpoint failures. Use inventory, maintenance groups and drift checks to keep control.

Safeguard Security Team
4 min read

Endpoint security management is hard because the fleet never stands still: devices appear unmanaged, patches get postponed, policies drift and staff work from anywhere. The fixes are unglamorous. Keep a near-complete inventory, group devices by maintenance needs, patch on a routine, and measure drift instead of assuming compliance.

Why can't you manage what you cannot see?

NIST SP 800-40 Rev. 4 starts patch management with inventory. It says organizations should establish and constantly maintain up-to-date software inventories for physical and virtual assets, including operational technology, Internet of Things and containers. It admits that a fully comprehensive inventory may be impossible given how dynamic assets are, and sets a realistic goal: close to comprehensive, using automation to constantly discover new assets and collect current information. It adds that without constant updates inventories quickly become outdated.

That wording is useful. The goal is not perfection but a known, shrinking gap.

What does the unmanaged device problem look like?

Constructed example: a security team reports 98 percent of its laptops patched. The count comes from the management console. Fifty contractors use their own laptops for a project, a few engineers run personal test machines, and a set of lab servers were never enrolled. The 98 percent is accurate for the population it measures and misleading for the company.

Zero trust architecture addresses this indirectly. NIST SP 800-207 says zero trust assumes no implicit trust granted to assets or user accounts based on ownership, whether enterprise or personally owned, and that authentication and authorization happen before a session is established. Device state becomes an input to access decisions, which gives you a reason to care about posture beyond the patch report.

Why do patches get postponed?

NIST states it plainly. Routine patching lacks urgency and can interrupt operations, such as through device reboots, so it is often postponed and neglected, which opens many windows of opportunity for attackers. Delaying also makes emergency patching harder, because earlier patches that new ones depend on must be installed first.

The structural fix is maintenance groups. NIST describes assigning each asset to a group of assets with similar characteristics that generally have the same maintenance needs: patch schedule, testing needs, outage restrictions and the impact if the software is compromised. A kiosk, a developer laptop and a payment server each get a different plan. It also defines separate scenarios for routine patching, emergency patching and emergency mitigation, so you decide in advance how a crisis differs from a normal week.

How does policy drift happen?

Settings change by hand, an exception is added for one team and never removed, and a tool is turned off to fix a performance complaint. Host controls can also be switched off by an attacker with administrator rights. NIST's firewall guidance recommends centralized management so policy is created, distributed and enforced consistently wherever a user connects.

What about remote and mobile staff?

Devices outside the office never see your network controls. NIST's firewall guidance notes that personal firewalls protect PCs both inside and outside the perimeter and can use separate profiles for untrusted networks, so the control travels with the machine. Remote devices need agents that report over the internet, patching that does not depend on a corporate network, and conditional access rather than a VPN checkbox.

How to check or apply this

  1. Compare your management console, identity provider device list and network scan. Every device in one and not another is a finding.
  2. Automate discovery of new assets and make enrollment a step in provisioning.
  3. Define maintenance groups with a written patch schedule and an outage rule for each.
  4. Set a time limit for routine patches and report the percentage past due by group.
  5. Pre-write the emergency patching and emergency mitigation procedures, with named approvers.
  6. Check configuration against a baseline weekly and list the devices that drifted.
  7. Use device compliance as a condition for access to important applications.
  8. Offboard devices as carefully as you onboard them, including a wipe or retrieval step.

Quick check

What is a maintenance group?

NIST SP 800-40 Rev. 4 defines it as a set of assets with similar characteristics that generally have the same maintenance needs, such as patch schedule, testing and outage limits.

Is a complete asset inventory realistic?

NIST says full coverage may be impossible and recommends a close-to-comprehensive inventory, kept current through automated discovery.

Sources

Last reviewed: 18 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.