For teams working through competing priorities
A list of critical findings does not explain which systems are affected, whether two tools describe the same issue or what the business can safely change. Security and IT teams need enough context to choose work and defend that decision.
ThreatShield connects application and vulnerability evidence with reporting and remediation workflows. It can support an organisation consolidating existing tools, reviewing an application estate or building a more accountable patching process. The first step is to establish which inventories and vulnerability sources can actually provide evidence.
What the available evidence can show
Supported integrations include Tenable, Qualys and Rapid7, alongside endpoint sources and on-premises application collection. Coverage differs between those paths. The reporting workflow includes a consolidated register for supported endpoint findings, on-premises software findings and Microsoft Defender device-to-vulnerability associations.
Where source fields allow, that register brings together a host, product and CVE, while retaining source observations and disagreements. Different names or uncertain device identity can leave separate rows that need review. Source connection status, collection success and the presence of usable records matter as much as the apparent finding count.
Prioritisation that explains its inputs
Severity is a starting point. Available on-premises vulnerability enrichment can also use CISA Known Exploited Vulnerabilities context, EPSS and public exploit availability. Those inputs support a more informed review of urgency alongside the affected system and its operational importance.
Not every provider supplies the same intelligence. A row without an exploitation-based priority is unmeasured on that basis; it is not automatically lower risk. Version matches, fixed releases and conflicting observations may need investigation before a team chooses a patch, configuration change or other response.
From a finding to a reviewed outcome
Confirm the affected system and proposed change, assign the work and review service impact. Supported remediation uses approved recipes and the applicable tenant, host and policy controls. Unattended dispatch also depends on configured authorisation, maintenance windows and other action limits. Read-only engagements remain advisory.
Recipe coverage varies, and some findings require a manual change plan. Deployment or assignment is not evidence that an application is installed or the exposure removed. Review fresh inventory or assessment evidence after the work, retain unresolved findings, and keep unavailable sources distinct from a verified clean result.
Questions about Vulnerability management
Can we keep our existing vulnerability tools?
ThreatShield supports connections for Tenable, Qualys and Rapid7, as well as other endpoint and inventory sources. Confirm the required product, API access and available data when scoping the connection.
Can every vulnerability be fixed automatically?
No. Automated work is limited to supported, authorised actions that pass the relevant policy controls. Missing recipes, higher-impact changes or unresolved evidence require another reviewed next step.
Does a missing finding prove that a system is fixed?
Only comparable, successful collection can support that conclusion. A disconnected source, failed collection or device that stopped reporting can also make a finding disappear.