Empirical Security

You need a full vulnerability management platform with scanning, asset discovery, and patching workflows out-of-the-box

• Alternatives to consider
  • Tenable, Qualys, or platforms embedded in your ITSM (ServiceNow Vulnerability Response) depending on your environment.

You require clearly published pricing for budgeting / procurement simplicity

• Empirical does not publish pricing in the accessible materials reviewed.

Your organization cannot support local-model enablement

• If asset inventory/CMDB is unreliable or exposure context is missing, the organization-specific modeling value proposition may be reduced.

You require extensive third-party review validation before purchase

• Empirical has limited accessible verified review quotes and limited community first-hand implementation discussion compared to major incumbents.

You have strict security/compliance gating that depends on public attestations

• SOC 2 / ISO 27001 status is not publicly documented in the reviewed sources.

Public limitations acknowledged by vendor

• No explicit vendor-maintained "known limitations" page was found in accessible sources; documentation is primarily API-oriented.

Roadmap / future features

• Not published as a formal roadmap with dates in the accessible sources reviewed.

Scale limitations

• Not publicly documented in the accessible sources reviewed.

Security or compliance documentation gaps

• Public documentation is insufficient to confirm SOC 2, ISO 27001, data residency options, or specific enterprise IAM features.

API/integration constraints

• Documentation emphasizes model keys and APIs; buyers should validate rate limits, SLAs, uptime commitments, and how model updates affect downstream workflows.

Public case studies

• No detailed, independently verifiable customer case studies with named customers and hard metrics were found in the sources reviewed.

Vendor-published performance claims (need verification)

• The vendor reports higher coverage and efficiency relative to some traditional methods or off-the-shelf models and states it publishes supporting data for its performance claims.
• Critical evaluation
  • Without independent replication or third-party validation, these vendor-reported claims should be validated via:
    • a time-bound pilot,
    • backtesting against the buyer’s historical exploitation/remediation outcomes,
    • measurement of catch rate for exploited vulnerabilities and reduction in wasted patch effort.

• A direct Empirical Security product listing with quotes was not found in the accessible Gartner Peer Insights pages during this research. Gartner Peer Insights itself is accessible, but Empirical-specific verified review quotes were not located.

• No Empirical Security product page with review quotes was found in the accessible TrustRadius pages during this research.

• G2 has an Empirical Security alternatives/competitors page (suggesting Empirical is recognized as a product entity in G2’s taxonomy), but this page primarily lists alternatives and does not provide user review quotes about Empirical itself in the accessible content.

• No substantive Reddit or Hacker News threads were found that clearly describe first-hand usage experiences of Empirical Security as a deployed product (as distinct from generic discussions). This creates a major limitation: there is little publicly available independent customer feedback for Empirical itself.

• Founding team background in risk-based vulnerability management and EPSS is emphasized in Empirical’s own research portal and public announcements.
• The vendor states that it publishes research and data to support model performance claims (this is a vendor-reported practice and should be validated by buyers).

• Lack of independent, high-volume user reviews makes it harder to validate:
  • accuracy vs competitors,
  • operational impact,
  • support quality,
  • ease of integration.
• Buyers should treat performance and coverage claims as provisional until verified in a pilot or other independent evaluation.

Empirical Security provides models that output a probability of exploitation for vulnerabilities (CVEs) to support risk-based vulnerability prioritization and remediation decisions. The vendor frames this approach as intended to move beyond severity-based prioritization (CVSS) and generic exploit-likelihood (EPSS) toward predictions grounded in observed exploitation data and, optionally, organization-specific inputs.

Core product packaging (as described by Empirical)

• Foundation
  • A global model that combines internet exploitation telemetry with EPSS and vendor-monitored signals covering a large set of exploited CVEs (vendor-reported coverage varies across vendor materials).
• Radiant
  • A local (organization-specific) model that uses Foundation inputs plus customer environment data (assets/config/internal telemetry) to predict exploitation risk specific to that organization.
• APIs / developer access
  • Documentation references a Foundation Models API, EPSS Models API (enterprise support for EPSS including higher-frequency updates and legacy EPSS model support), and Radiant Models API for enterprise-specific modeling. It also references model keys such as global and epss_v3/v4/v5 for API usage.

Primary buyers/users

• Security and risk leaders responsible for vulnerability management and exposure management programs (CISO org, vulnerability management leads, SecOps, security engineering).

Positioning

• The vendor positions the product as a modeling layer intended to inform prioritization and decision support and to operate alongside existing scanners and ticketing systems rather than replacing them.
• The vendor highlights explainability of prioritization decisions via indicators described as "critical indicators"; these are vendor-provided explanatory signals for model outputs.