Endpoint scanning is the routine check of each laptop, server and workstation for missing patches, known vulnerable software and risky settings. It answers one question: what is wrong on these devices right now? It only works if you also know which devices exist, so scanning and inventory are two halves of one job.
What does NIST require?
Control RA-5 in SP 800-53 Rev 5 asks organizations to monitor and scan for vulnerabilities in the system and hosted applications on a defined schedule and whenever new vulnerabilities that may affect the system are reported. It also asks for tooling that automates parts of the process using common standards for naming platforms and flaws, analysis of the results, remediation within defined time frames based on risk, and sharing what is learned so similar flaws are fixed elsewhere.
CM-8 asks for an inventory of system components that accurately reflects the system, includes all components and avoids duplicates. Without it, a scan reports on the devices you remembered.
Why does inventory come first?
NIST SP 800-40 Rev 4, on enterprise patch management, says organizations should maintain up-to-date software inventories for physical and virtual assets, including operational technology, IoT and container assets. It adds that a comprehensive inventory may be impossible given how dynamic assets are, and says a realistic goal is a close-to-comprehensive inventory that relies on automation to keep discovering new assets and collecting current information. It also notes that software bills of materials from vendors can augment inventories.
That framing is honest. You will never have a perfect list, so scan to find what is missing from the list too.
How do you decide what to fix first?
Not every finding deserves the same urgency. CISA maintains the Known Exploited Vulnerabilities catalog, a list of vulnerabilities with reliable evidence of active exploitation. CISA's Binding Operational Directive 22-01 created it and required federal agencies to remediate catalog entries. The directive page now says it has been revoked and superseded by BOD 26-04, which this article does not cover. The catalog itself remains a practical input for anyone: a finding that also appears in it moves to the top of your queue.
Constructed example. A scan returns 1,400 findings across 220 devices. Eleven match the known exploited list, and three of those are on internet-facing servers. Those three are Monday's work. The remaining 1,389 get sorted by exposure and by whether the vulnerable component is actually in use.
Credentialed or not?
An unauthenticated scan sees what the network sees: open ports and banners. A credentialed or agent-based scan reads installed software, patch levels and configuration from inside the device. The second kind finds far more but needs trusted access, so protect the scanning account like any privileged identity.
How often should it run?
NIST leaves the number to you. A sensible pattern: continuous or daily collection for managed laptops and servers, a scan within a day or two after a high-profile disclosure, and monthly full runs with review. Short-lived assets such as build runners and containers need scanning at build time, since they may not exist when the monthly job runs.
How to check or apply this
- Build the inventory first, from your device management, identity provider, cloud account lists and network discovery.
- Reconcile the sources and list devices that appear in one source but not another. Those are your blind spots.
- Choose an agent or credentialed scan for managed devices, and protect the credentials.
- Add the known exploited catalog as a priority filter.
- Set remediation targets by risk class, and record exceptions with an owner and an expiry date.
- Trigger an extra scan after a major disclosure.
- Report on coverage as well as findings: what share of known devices was scanned this week?
Where Safeguard fits
Endpoint scanning looks at devices. Safeguard works one layer up, on the software you build: SBOM and dependency scanning and reachability analysis show which vulnerable packages in your applications can be reached by your code. It complements device scanning and does not replace it.
Quick check
Does a clean scan mean a device is safe?
No. It means no known issues were found within the scan's checks. Unknown flaws, stolen credentials and unscanned devices are outside it.
Why track scan coverage?
A report with few findings may simply reflect few devices scanned. Coverage tells you whether a good result is meaningful.
Sources
- NIST SP 800-53 Rev 5 control catalog, OSCAL (RA-5, CM-8)
- NIST SP 800-40 Rev 4, Guide to Enterprise Patch Management Planning
- CISA Known Exploited Vulnerabilities Catalog
- CISA Binding Operational Directive 22-01
Last reviewed: 18 October 2026.
