TL;DR: Your exposure can change even when no new CVE is published. Vendors revise affected-version ranges, previously disclosed CVEs appear in CISA's Known Exploited Vulnerabilities catalog, and newly managed endpoints bring older vulnerabilities back into scope. These changes should trigger a fresh assessment, with uncertain matches tracked and fixes verified before findings are closed.
To monitor new CVEs for software you actually run, maintain a current software inventory, follow vendor advisories and CVE data sources, and match affected versions to your endpoints. Track updates to existing CVEs as well as new disclosures, and route confirmed matches to the right owner.
The practical problem is connecting CVE information to software actually installed in your environment and noticing when something changes.
Which software should your CVE monitoring cover?
Start from inventory, not intuition. The applications you think you're running and the applications actually installed across endpoints are rarely the same list.
Build a watchlist from your current software inventory. For each entry, capture:
Publisher and product name
Installed version or build
Operating system
Associated devices
Responsible owner
Date the software information was last verified
Inventory data can get outdated quickly. If a device hasn't been checked in three weeks, you can't be sure which software version it's running.
Your watchlist should also flag gaps, such as unmanaged devices, software components outside scanner coverage, and anything your inventory doesn't reliably see. Assign those gaps to an owner too. Unknown exposure is still exposure.
Your inventory doesn't need to be perfect, but it should give you enough information to determine whether a security advisory applies to your environment.
Where should you monitor CVE disclosures?
Knowing which sources to watch is only half the job. The other half is making sure information actually reaches someone who can act on it.
Source | What to use it for | How to monitor it |
|---|---|---|
Vendor security advisories | Product-specific affected versions, fixes, mitigations, and revised guidance | Subscribe to the vendor's notification service where available. Microsoft's Security Update Guide, for example, supports email notifications for both new CVEs and revisions to existing ones. |
Authoritative CVE identifier, affected products and versions, supporting references | Use records to verify the issue and reconcile references from different sources. A CVE record is a description of the vulnerability; it is not evidence that your endpoints are affected. | |
Searchable CVE data with severity metrics and applicability information | Use NVD's APIs or an appropriate integration. NVD distinguishes recently published records from modified records, which matters for ongoing monitoring. | |
CVEs with confirmed exploitation in the wild | Check catalog additions against software you're already tracking. KEV is an important input, not a complete list of everything that could matter. |
For Microsoft software, subscribe to Security Update Guide notifications and review both new disclosures and revisions against your watchlist. Those emails won't know which Microsoft products you have installed, so you'll still need to check. But they will tell you when something changed that is worth investigating.
A note on NVD: Don't assume every CVE gets immediate enrichment. A significant backlog of unenriched CVEs was publicly noted in early 2024, and NIST announced a risk-based prioritization model for NVD enrichment on April 15, 2026, so some CVEs remain listed without complete severity data. Missing enrichment shouldn't block investigation of a relevant vendor advisory.
How do you catch new CVEs and changes to existing ones?
This is where most monitoring workflows break down. Teams set up alerts for new disclosures, then miss everything else that matters.
Newly published, newly changed, and newly relevant to your environment are three different events. Your monitoring needs to catch all of them.
Four events that should trigger a check:
A new disclosure appears. Check whether the affected product is on your watchlist.
An existing advisory or CVE changes. Reassess when affected versions expand, remediation guidance updates, or other material details shift.
Exploitation information changes. An older CVE's addition to KEV warrants renewed attention, even without a new disclosure.
Your environment changes. A newly installed application or newly managed device may introduce exposure to a CVE you already knew about.
NVD supports publication and modification queries. Microsoft distinguishes advisory revisions. KEV tracks additions separately. Those source behaviors support the first three events. The fourth requires your own inventory-driven reassessment.
How do you avoid gaps in CVE monitoring?
Monitoring new disclosures is only part of the process. You'll also need to account for existing vulnerabilities, changes to CVE records, and advisories that don't have CVE identifiers yet.
Check for existing vulnerabilities when adding software. Run a baseline check whenever you start monitoring a new application. Otherwise, you could miss vulnerabilities disclosed before you started tracking it.
Track publication and revision dates. Record when a CVE was published, when it was last updated, and when your team first identified it. The year in a CVE identifier doesn't necessarily indicate when the vulnerability was discovered.
Deduplicate CVE records. Combine references to the same CVE from multiple sources, but continue tracking revisions that could change which devices are affected.
Monitor advisories without CVE identifiers. Vendors sometimes publish security guidance before a CVE is assigned. Don't require a CVE number to begin investigating a potential vulnerability.
For example, a team might identify an existing CVE when it starts monitoring an application. Later, the vendor could expand the affected-version range, prompting another inventory check. A month later, a newly enrolled endpoint may introduce another affected installation. In this scenario, the CVE hasn't changed, but the team's exposure has.
Keep in mind that CVE monitoring can only help you track disclosed vulnerabilities. It won't identify vulnerabilities that haven't been publicly disclosed.
How do you confirm which endpoints are affected?
External information tells you a vulnerability exists. Local inventory tells you whether it matters to your environment.
Compare the advisory's affected product, version range, platform, and stated conditions against current endpoint evidence. A matching application name or an "outdated" label is not confirmation of a particular CVE ... you need version-level specificity.
Work toward three investigation outcomes:
Affected: Evidence confirms the vulnerable version is installed.
Not affected: Available evidence rules out exposure.
Needs investigation: Missing version data, stale inventory, or unresolved coverage questions.
Keep in mind that a missing version or stale check-in should not become a clean result by default. Any uncertainty should stay visible until it's resolved.
How does PDQ help identify affected devices?
PDQ automatically scans managed devices for known CVEs and shows which endpoints are affected. Vulnerabilities are prioritized by PDQ Risk Score, with remediation guidance and recommended fixes where available.
When a vendor updates an advisory or your environment changes, you can review current software inventory and run a new scan to reassess affected devices. This helps you keep track of vulnerabilities as software versions and endpoint inventories change.
For confirmed vulnerabilities, PDQ lets you deploy patches to affected devices or automate remediation when recommended packages are available. After deployment, PDQ automatically rescans affected devices to help you verify whether the vulnerabilities have been resolved.
How do you keep CVE monitoring actionable?
To keep CVE monitoring actionable, assign an owner to each finding, document what changed, and make the next step clear. A list of vulnerabilities isn't much use if nobody knows who's supposed to follow up.
Each monitoring record should include:
CVE or advisory identifier
What changed (new disclosure, revision, KEV addition, environment change)
Source and revision timestamp
Affected software from your watchlist
Identified devices
Evidence freshness
Applicability status
Responsible owner
Next action
According to PDQ's State of Sysadmin report, 51% of sysadmins say timely security patch implementation takes up too much time, and another 51% cite monitoring and responding to security threats as a major time drain. Having a consistent process for reviewing and assigning findings can help keep that workload manageable.
As a starting point, assign someone to review findings daily, establish an out-of-cycle escalation process for significant disclosures, and check weekly for failed source collection, outdated inventory, and unassigned findings. Adjust the schedule based on your environment and response requirements.
PDQ's scheduled reports can help with regular reviews by emailing results from the most recent report run. This gives your team a consistent way to review vulnerability information alongside other monitoring activities.
Use factors like confirmed exploitation, exposure level, and business impact to prioritize vulnerabilities and determine which findings need immediate attention. Once a vulnerability is confirmed and prioritized, assign it to your remediation workflow and verify the fix.
Ultimately, CVE monitoring should help you answer two questions whenever something changes: Does this affect software we have, and who needs to act?
If you're managing endpoints at scale and want vulnerability visibility that connects to remediation, PDQ handles the overlap between finding what's exposed and fixing it.
Find and fix vulnerabilities faster
PDQ helps IT teams simplify vulnerability management from detection to remediation. Spot, prioritize, and remediate CVEs from anywhere. View vulnerabilities by device or software. Then filter by risk, severity, affected software, impacted devices, and more to identify high-priority exposures and patches.
