The Complete Guide to Continuous Threat Exposure Management (CTEM)

Continuous Threat Exposure Management, or CTEM, is how security teams move from periodic vulnerability scanning to something that actually keeps pace with how fast threats change.

Most CTEM programs stall at the same place: Mobilization. The first four stages (Scoping, Discovery, Prioritization, and Validation) get the investment and the attention. The fifth stage, where confirmed findings actually move into engineering workflows and get fixed, is where the program quietly breaks down. HackerOne has processed more than 580,000 validated vulnerabilities across thousands of programs. What that data shows about where CTEM fails in practice is different from what the framework documents describe.

By 2026, Gartner predicted that companies prioritizing a continuous exposure management program would face breach risk at one-third the rate of those sticking with conventional methods.¹

HackerOne's research reinforces the point: organizations that formally test 91% or more of their AI systems are 16% less likely to report an attack, and those leaving the largest gaps in coverage carry nearly $730K more in annual remediation costs than those that don't.²

And H1 Platform data shows vulnerability submissions up 92% year-over-year, while remediation throughput lags. The gap between what gets found and what gets fixed is the central operational problem facing security teams.

This guide covers what CTEM is, why it's replacing periodic scanning, how the 5-stage framework works in practice, how it applies to AI systems, and how to build a program, including the mistakes most teams make along the way.

What Is Continuous Threat Exposure Management (CTEM)?

Continuous Threat Exposure Management (CTEM) is an adaptive security framework designed to continuously measure, validate, and reduce an organization’s exploitable attack surface. It moves beyond static vulnerability management by combining automation, validation, and prioritization into a single operating motion.

The term Continuous Threat Exposure Management (CTEM) was coined by Gartner in 2022. It has since been named a top security investment for 2026, and Gartner published its first Magic Quadrant for exposure assessment platforms in 2025. The analyst community's sustained attention reflects what practitioners are discovering on the ground: traditional vulnerability management was designed for a slower, simpler attack surface than most organizations now run.

The core question CTEM answers: "Of everything we know about, what can actually be exploited in our environment right now?"

That framing shifts the conversation from volume to validated, prioritized, business-contextualized risk. CTEM does not replace security tools, but creates the operating model that makes those tools meaningful in aggregate.

Image

The five stages, Scoping, Discovery, Prioritization, Validation, and Mobilization, run continuously, feeding each other in a cycle. Each stage builds on the last, with the program's value compounding over time as teams develop richer context about their environment, their adversaries, and their remediation velocity.

HackerOne has observed CTEM programs across every maturity level, from organizations running their first scoping exercise to enterprises with fully operationalized five-stage cycles.

A pattern shows programs that invest heavily in Discovery and Prioritization, then treat Validation as a checkbox, and Mobilization as the place findings go to stall. The result is a well-organized vulnerability list masquerading as a risk reduction program. The rest of this guide is built around that observation: what CTEM looks like when all five stages are real, and what it costs when one of them isn't.

There’s a difference between nominal CTEM and structural CTEM:

• A nominal CTEM program has all five stages on paper. It has a scope document, a scanner feeding Discovery, a prioritization queue, maybe a quarterly pentest sitting in the Validation row of a spreadsheet, and a ticketing workflow for Mobilization.
• A structural CTEM program has all five stages running continuously, feeding each other, with Validation generating adversarially confirmed findings on a cadence that matches how fast the environment changes. Most organizations that say they run CTEM are running the nominal version.

Why Vulnerability Management Alone Is No Longer Enough

The scope problem: Traditional vulnerability scanners only see what they're pointed at. They miss shadow IT, unmanaged SaaS deployments, third-party APIs, and the AI systems now embedded across nearly every enterprise environment. What isn't scoped can't be managed, and attackers don't limit themselves to your known inventory.

The cadence problem: Quarterly scans measure a world that changes daily. Research shows 61% of threat actors deploy new exploit code within 48 hours of a vulnerability becoming known, meaning the window between disclosure and active exploitation has largely collapsed. A scanner run that finishes on Monday is already outdated by Wednesday. Continuous exposure management requires continuous discovery.

The validation problem: Scanner-confirmed existence is not adversarially confirmed exploitability. Organizations that treat scanner output as validation have not built a CTEM program. They've built a more expensive version of the vulnerability management they were trying to replace.

CTEM vs. Vulnerability Management: Scanning Is No Longer Enough

The 5 Stages of the CTEM Framework

The five-stage CTEM cycle is the defining structure of the program. Each stage has a distinct function, a common failure mode, and a set of tools and practices that make it work. Understanding all five, and how they connect, is a prerequisite to building a program that actually reduces risk.

Stage 1: Scoping

Scoping defines what the CTEM program exists to protect. The critical discipline here is starting with business-critical systems, not IP ranges, not CVE lists, and not whatever assets are already under your scanner's management.

Modern scope includes external attack surface, SaaS environments, cloud infrastructure, third-party APIs, identity systems, and increasingly, AI and ML deployments. Each of these categories represents real exploitable risk. Each is routinely left out of programs that inherit their scope from legacy scanner configurations.

Common mistake: Scoping only the assets teams already manage. This leaves shadow IT, unmanaged SaaS, and AI deployments entirely outside the program. Every subsequent stage inherits these blind spots, which means Prioritization, Validation, and Mobilization are all operating on an incomplete picture of the environment. Attackers don't scope to what security teams manage, they scope to what the organization runs.

Effective scoping is not a one-time exercise. As the business adds SaaS tools, acquires companies, or deploys AI systems, scope must expand to match. CTEM programs that treat scoping as a setup step rather than a continuous discipline drift out of alignment with the real attack surface within months.

What gets scoped in Stage 1 determines what Validation can confirm in Stage 4. Assets left outside the scope boundary in this stage cannot be adversarially validated later, regardless of how mature the rest of the program becomes.

Stage 2: Discovery

Discovery is where the program identifies actual exposures across the scoped environment. Discovery in a CTEM program goes beyond CVEs. It encompasses logic flaws, privilege escalation paths, insecure API behaviors, misconfigurations, identity exposures, shadow IT, and AI-specific risks: the categories of risk that scanners systematically miss.

The scale of the discovery challenge is significant. In 2024 alone, nearly 40,000 new CVEs were disclosed. That figure doesn't include the logic flaws and chained exploits that never receive a CVE assignment but represent real attack paths. Discovery must be continuous, not periodic, to stay current with an environment that changes frequently and a threat landscape that outpaces quarterly scanning cadences.

To make that concrete: a misconfigured OAuth delegation path that allowed a researcher to escalate from a low-privilege API token to admin access across three connected services would not appear in a CVE list, would not trigger a scanner alert, and would not surface in a CVSS prioritization queue. It requires a human to ask how those services interact under adversarial conditions. Discovery that stops at CVEs misses the finding class that tends to matter most in a real breach.

Common mistake: Treating discovery as a scanner run. Scanners are a component of discovery, not a substitute for it. Human security researchers find vulnerability classes, novel attack chains, business logic flaws, and privilege escalation paths that automated tools cannot identify. A CTEM discovery function needs both.

The external attack surface deserves particular attention at this stage. Assets that face the internet are the first exposure class attackers target, and they are frequently the least well-inventoried. Continuous asset discovery must precede and remain synchronized with vulnerability discovery.

Discovery produces a list of potential exposures. Stage 4 determines which ones are real. The quality of what gets validated depends entirely on the quality of what Discovery surfaces, which is why programs that run Discovery narrowly, relying on scanner output alone, tend to find Stage 4, confirming a skewed picture of their actual risk.

Stage 3: Prioritization

Prioritization is where CTEM diverges most sharply from traditional vulnerability management. Classic prioritization uses CVSS scores as a proxy for risk. CTEM uses CVSS as one data point among several, alongside asset criticality, active threat intelligence, exploitability in the specific environment, and reachability from attacker-accessible entry points.

The work queue changes. A CVSS 9.8 vulnerability on a non-internet-facing, non-critical internal system may rank below a CVSS 6.5 vulnerability with active exploit code in the wild, on a system directly accessible to external attackers and adjacent to sensitive data. Risk-ranked prioritization is also a more defensible one when a board asks why a breach happened.

Common mistake: Letting CVSS scores drive remediation queues without layering in business context. This produces high-volume, low-yield remediation work: teams spending engineering cycles on findings that don't materially reduce breach risk while genuinely exploitable exposures wait in the queue.

AI-assisted prioritization has become a practical force multiplier at this stage. HackerOne's Hai demonstrates what's achievable: 95% triage accuracy, 40% improvement in signal quality, and a reduction in prioritization decisions from hours to seconds. When prioritization decisions are faster and more accurate, Validation and Mobilization can operate at the speed the threat environment requires.

Prioritization tells you what to validate first. It doesn't tell you whether those findings are exploitable in your environment. That answer only comes from Stage 4.

Image

HackerOne Hai

Hai powers every stage

Learn more about Hai

Stage 4: Validation

Validation is the hardest stage and the most commonly skipped. Most programs run Discovery and Prioritization reasonably well and treat Validation as optional, a layer that gets cut when resources are constrained. It is also the stage where programs most commonly lose their claim to the CTEM label.

That trade-off misunderstands what Validation does. Without adversarial confirmation that a finding is actually exploitable in your environment, CTEM produces a better-organized vulnerability list, not a risk reduction program. H1 Platform data shows that only 25% of vulnerability submissions are confirmed valid and exploitable, meaning the majority of unvalidated findings in a typical queue are noise. Without a validation layer, those findings don't disappear; they absorb remediation capacity that should be applied to confirmed risk.

Validation methods include:

• Breach and Attack Simulation (BAS): Automated testing of security controls in simulation. Effective for known attack patterns; limited against novel threat actors.
• Penetration Testing as a Service (PTaaS): Structured, ongoing agentic pentesting security engagements that deliver continuous validation without the scheduling constraints of traditional pentests.
• Bug bounty programs: Always-on validation by elite researchers who surface chained exploits, business logic flaws, and novel attack paths that automated tools are not designed to find. Bug bounty functions as CTEM's continuous red team layer.
• AI red teaming: Validation designed for AI and LLM systems, including prompt injection, policy bypass, and model manipulation testing.

What that looks like in practice: a researcher receives a scope brief and begins mapping how services authenticate to each other, not looking for known CVEs but asking what assumptions the system was built on and whether those assumptions hold under pressure.

The scanner ran the day before and found nothing critical. Within hours, the researcher has identified a token delegation flow where a low-privilege service account can request elevated permissions from a higher-privilege service by spoofing a header value the system was never designed to validate externally. No CVE. No CVSS score. Fully exploitable. That finding comes from someone asking a question the tool wasn't designed to ask.

Common mistake: Relying exclusively on automated validation. BAS and scanners test for known patterns. Human researchers test for unknown ones. The findings that matter most to adversaries, the chained exploits, the logic flaws, the novel paths, are the ones automated validation doesn't surface. A Validation stage without a human component has a systematic blind spot.

This is HackerOne's central value proposition in a CTEM program. Adversarial exposure validation, powered by a community of security researchers, provides the extra validation layer that automated tools cannot replicate.

The findings that matter most to adversaries (chained exploits, business logic flaws, novel attack paths, AI-specific vulnerabilities) are consistently absent from automated validation outputs. Not because the tools are poor, but because these finding types require human adversarial judgment to surface. 

A researcher asks what an attacker would do with access to this system, and then does it. Current automated tools are not built for that question. Current simulations are not a substitute for that answer.

Stage 5: Mobilization

Mobilization is where validated findings become remediated risk and where the cycle becomes self-improving. What Engineering learns about which findings are most operationally disruptive to fix, and which asset classes carry the most business risk, feeds back into Stage 1 to sharpen the next round of scoping. Each iteration makes the next one more accurate. This is why CTEM's value compounds over time in a way that periodic assessments cannot.

Without Mobilization, CTEM is a reporting exercise. A program that consistently discovers, prioritizes, and validates risk, but routes findings to a queue that Engineering ignores, has not reduced the organization's exposure.

The measure of a CTEM program's effectiveness is confirmed risk reduced, not vulnerabilities found. This is also CTEM's most common structural failure point. Of the five stages, Mobilization is the one most dependent on organizational accountability that security teams don't control.

Remediation capabilities in the H1 Platform close the discovery-to-remediation gap by delivering developer-ready fix guidance with full exploit context, routed automatically to the right owner, with retests to confirm fixes hold.

Integration matters: Mobilization requires meeting engineering teams where they work. HackerOne integrates with Jira, ServiceNow, GitHub, Azure DevOps, and 36+ additional platforms. Findings that route directly into existing development workflows get fixed faster than findings that route into a separate security queue. Friction in the Mobilization stage directly increases mean time to remediation.

Common mistake: Measuring CTEM program performance by discovery volume: scans run, vulnerabilities found, reports generated. These activity metrics don't capture whether risk is actually decreasing. The right metrics are MTTR (mean time to remediate), confirmed exposure backlog, and validated risk reduced over time. Boards fund outcomes, not activity.

The New Metrics That Matter: How to Brief Your Board on AI-Accelerated Exposure

CTEM vs. VM, EASM, BAS, and Red Teaming

• CTEM vs. Vulnerability Management: VM is a component of CTEM that powers the Discovery stage. CTEM adds Prioritization by business context, adversarial Validation, and structured Mobilization.
• CTEM vs. External Attack Surface Management (EASM): EASM covers external asset discovery. It answers what we have at the perimeter. CTEM adds internal scope, identity systems, SaaS, AI deployments, and the Validation and Mobilization loops that EASM doesn't include. EASM is an input to CTEM's Scoping and Discovery stages.
• CTEM vs. Breach and Attack Simulation (BAS): BAS tests security controls by simulating known attack patterns. CTEM integrates BAS into a continuous program cycle with business-aligned Prioritization and structured Mobilization. BAS is one method used within CTEM's Validation stage, not a substitute for the full program.
• CTEM vs. Red Teaming: Red teams deliver deep, periodic adversarial insight, valuable for testing defenses against sophisticated attack scenarios. CTEM operationalizes that adversarial mindset into a continuous cycle. Bug bounty programs function as CTEM's always-on red team layer, providing continuous validation between periodic engagements.

CTEM for AI Systems

CTEM wasn't designed specifically for AI systems, but the 5-stage cycle maps onto the AI attack surface. For organizations that have deployed AI systems in production, that footprint has become one of the fastest-growing and least-tested exposure classes they manage.

• The vast majority (94%) of organizations expanded their AI footprint in the past year, but only 66% formally test more than 60% of their AI systems.2 
• Prompt injection reports increased 540% in a single year, and AI-related security testing is up 270% on the H1 Platform.3

These numbers describe an exposure class that is growing faster than the security programs designed to manage it.

The organizations getting CTEM right are the ones that extended the program to AI before anyone told them they had to. The AI attack surface is where the distinction between nominal CTEM and operational CTEM shows up first, because AI systems don't fit inside scanner perimeters, don't generate CVEs, and don't respond to the validation methods that work everywhere else.

Every CTEM stage applies to AI systems. The application is direct, but the specifics are different enough from traditional assets to warrant mapping explicitly.

Organizations extending CTEM into their AI footprint are ahead of a regulatory and operational curve that is moving fast. In practical terms, extending scope means adding AI models, LLM APIs, agent workflows, training pipelines, and the prompt injection attack surface to the perimeter that Scoping defines, none of which appear in a traditional scanner inventory.

Who Owns CTEM in Your Organization?

CTEM is cross-functional by design. It touches security operations, offensive security, engineering, and executive leadership. Without clear ownership at each stage, the program stalls, typically at the Validation or Mobilization stage, where cross-functional coordination is hardest.

• CISO: Sets program strategy, defines KPIs, and owns board-level reporting. The CISO is accountable for the program's outcomes, not its operational execution. This means translating CTEM results into risk language that boards and CFOs understand, not managing individual vulnerability queues.
• Security Operations (SecOps): Runs Discovery and alert triage. SecOps is the operational engine of the CTEM cycle, responsible for maintaining continuous discovery coverage, processing incoming signals, and ensuring the program's asset inventory stays current as the environment evolves.
• Offensive Security: Owns the Validation stage. Whether internal red teams, PTaaS engagements, or a bug bounty program, the offensive security function is responsible for adversarially confirming exploitability before findings route to Engineering. This stage is the one most commonly outsourced, and most commonly skipped.
• Engineering: Owns Mobilization. Engineering teams are accountable for remediation, not for receiving tickets, but for closing them at the velocity CTEM requires. Programs that route Mobilization responsibility entirely to Security and treat Engineering as a downstream consumer consistently underperform on MTTR.
• Risk and Compliance: Owns board-level reporting and regulatory mapping. Risk and Compliance translates CTEM program outputs, validated risk reduced, MTTR trends, attack surface coverage, into formats that satisfy audit requirements and inform executive decision-making.

The programs that stall most reliably are the ones where Offensive Security owns Validation on paper, but the budget, tooling, and headcount to run it continuously don't exist. In those programs, Validation becomes a quarterly pentest with a new name: periodic, not continuous, and unable to keep pace with the discovery and prioritization stages it's supposed to confirm.

6 Common CTEM Implementation Mistakes

1. Scoping Too Narrowly

The most common failure mode in CTEM is inheriting scope from existing scanner configurations. Teams scope to known, already-managed assets and leave shadow IT, unmanaged SaaS, and AI deployments outside the program entirely. The consequence is that every subsequent stage operates on an incomplete picture of the attack surface. Attackers scope to what the organization runs.

2. Treating CTEM as a Project, Not a Program

Organizations frequently launch CTEM as an initiative, a 90-day sprint to implement the framework and declare success. CTEM is a continuous operating model. The value comes from running it continuously and improving each iteration. Programs that sunset after an initial implementation typically revert to periodic scanning within two quarters. CTEM's ROI is cumulative: the longer the program runs, the richer the environmental context, the faster the prioritization, and the stronger the Mobilization velocity.

3. Skipping the Validation Stage

Most programs run Discovery and Prioritization well, but treat Validation as optional, something that gets cut when budgets tighten or timelines compress. The result is a well-organized vulnerability list, not a CTEM program. Without adversarial confirmation that a finding is exploitable in your specific environment, remediation queues grow with unvalidated findings that may never have resulted in a breach.

4. Siloing CTEM in the Security Team

When Security owns CTEM and Engineering simply receives tickets, remediation velocity stays low. Engineering must be a co-owner of Stage 5. Programs that don't build that accountability in from the start consistently underperform on MTTR, regardless of how well the earlier stages run.

5. Reporting on Activity, Not Outcomes

The most common CTEM reporting failure is measuring scans run, vulnerabilities found, and tickets opened. These activity metrics are easy to collect and genuinely feel like progress. They do not tell boards, CFOs, or CISOs whether the organization's actual exposure is decreasing. The metrics that matter are confirmed risk reduced, MTTR trends, and validated exposure backlog that capture whether the program is delivering on its core purpose.

6. Treating Validation as a Stage Rather Than a Practice

Most programs approach Validation as a discrete activity: run the BAS, complete the pentest, check the box. CTEM's Validation stage is designed to be continuous. The moment Validation becomes periodic, the program has reverted to the cadence problem it was built to solve.

Continuous validation requires a mechanism that operates between scheduled engagements, which is why bug bounty programs function as CTEM's always-on Validation infrastructure rather than a supplementary security activity.

How to Build the Business Case for CTEM

Organizations with mature CTEM programs are 3x less likely to suffer a breach.1 Translated into financial terms against the 2025 global average breach cost of $4.44 million, that represents meaningful expected value and a credible basis for a board-level investment conversation. And across their programs, HackerOne customers have seen more than $32 billion in risk exposure mitigated.

Gartner projects that by 2028, organizations that combine CTEM with strong cross-functional Mobilization will see a 50% reduction in successful cyberattacks.4 For organizations in high-risk sectors or under increasing regulatory scrutiny, that projection is the investment horizon argument.

Three things every CISO needs to present on CTEM to a board:

• A before/after validated risk comparison showing exposure reduction. Not vulnerability counts, but confirmed exploitable exposures tracked over time, demonstrating that the program is actually closing the attack surface.
• An MTTR trend showing that remediation is accelerating. If CTEM is working, the time between finding and fixing should decrease as Engineering teams develop context and workflows mature.
• An attack surface coverage metric showing what percentage of the environment is under continuous validation. Boards understand coverage gaps. A metric showing that X% of the attack surface has continuous validation, and Y% does not, creates a concrete framing for investment decisions.

The organizations that build that case most credibly are the ones whose CTEM programs include adversarial validation data: what was found, what was confirmed exploitable, what was fixed, and how fast.

CTEM Maturity Model

CTEM programs don't emerge fully formed. Most organizations enter at an early stage, periodic scanning, CVSS-based prioritization, limited validation, and develop toward a mature, continuously operating program. Understanding where a program sits in this progression clarifies what the next investments should be.

The most important distinction the maturity model doesn't capture is between programs that have designed all five stages and programs that are actually running them. 

If you've inherited a CTEM program rather than building one from scratch, the question is whether what you've inherited is structural or nominal. Three questions that cut through the documentation:

1. When did Validation last run and what did it confirm?
2. Can you show a finding from human adversarial testing in the past 90 days? 
3. What was the last confirmed-exploitable finding Engineering closed, and how long did it take?

A program that answers all three with specific recent evidence is structural. A program that answers with reports and scheduled cadences is nominal. 

CTEM Across Industries

Financial Services

Financial institutions face converging pressures: PCI DSS 4.0 and SOX compliance requirements that demand continuous validation evidence, M&A-driven attack surface expansion, identity exposure as a primary threat vector, and real-time validation requirements driven by regulatory and reputational risk. CTEM provides the framework to meet these requirements continuously rather than through point-in-time assessments.

Healthcare

Healthcare environments combine legacy systems that can't be easily patched, connected medical devices with constrained remediation windows, HIPAA-aligned reporting requirements, and the operational constraint that security response must not disrupt patient care. CTEM's Prioritization stage, which ranks by business impact alongside exploitability, is particularly valuable in environments where not everything can be remediated immediately.

Public Sector

Government and critical infrastructure organizations operate under NIS2, DORA, and SEC cyber disclosure rules while managing environments with constrained patch windows and high-consequence failure modes. CTEM's continuous validation capability addresses the regulatory requirement for demonstrable, ongoing security management rather than annual assessment compliance.

AI-Native Technology

Technology organizations deploying AI as a core product capability face one of the fastest-growing attack surfaces in enterprise security. AI model validation, agentic workflow security, and developer-speed remediation requirements all map to CTEM's framework, but require AI-extended scope and AI red teaming capabilities.

Snap Inc. and HackerOne: Pioneering AI Red Teaming and Celebrating a Decade of Partnership

How to Start: Your First 30 Days

A fully operationalized CTEM program takes 90 to 180 days to build. The first 30 days are about establishing the foundation that makes the rest of the program work.

• Map scope around business-critical systems, not tool perimeters or existing scan configurations. Identify the assets that, if breached, would produce the highest business impact. Start there rather than with a full inventory exercise.
• Audit your current discovery coverage. Identify what's outside your existing scan perimeter today: unmanaged SaaS tools, AI systems, shadow IT, third-party integrations. This gap analysis is the program's baseline. It tells you what you don't know you don't know.
• Add a Validation layer. If you're currently confirming that vulnerabilities exist but not whether they're exploitable in your environment, you're missing the core of CTEM. A PTaaS engagement or bug bounty program can provide this layer without a long implementation runway.
• Build Mobilization into engineering workflows. Findings that route into a security-only queue don't get fixed at the speed CTEM requires. Connect validated findings to the ticketing and workflow tools Engineering already uses, Jira, GitHub, ServiceNow, and make remediation a joint accountability.

Start Building Your CTEM Program

CTEM is a continuously operating program that compounds in value over time. The H1 Platform is built to operationalize CTEM at every stage.

See how H1 Platform enables CTEM across discovery, validation, and mobilization

^{1. Gartner, "How to Manage Cybersecurity Threats, Not Episodes," 21 August 2023}

^{2. Closing the AI Security Gap: Containing Risk Before It Scales
Survey methodology: HackerOne surveyed 303 security leaders between January and February 2026. Respondents were screened to ensure they oversee or contribute to tracking, managing, or testing their organization’s AI/ML systems, and represent a range of senior security and offensive security roles within organizations reporting $250 million or more in revenue across the United States, Canada, the United Kingdom, Australia, Singapore, and Germany. Respondents represented multiple industries, led by Technology Hardware/Software (37%) and Banking/Financial Services/Insurance (16%), with additional representation across manufacturing, healthcare, retail/e-commerce, and other sectors}

^{3. Hacker-Powered Security Report 2025: The Rise of the Bionic Hacker}

^{Survey methodology: HackerOne and UserEvidence surveyed 99 HackerOne customer representatives between June and August 2025. Respondents represented organizations across industries and maturity levels, including 6% from Fortune 500 companies, 43% from large enterprises, and 31% in executive or senior management roles. In parallel, HackerOne conducted a researcher survey of 1,825 active HackerOne researchers, fielded between July and August 2025. Findings were supplemented with HackerOne platform data from July 1, 2024 to June 30, 2025, covering all active customer programs. Payload analysis: HackerOne also analyzed over 45,000 payload signatures from 23,579 redacted vulnerability reports submitted during the same period.}

^{4. Gartner, "Use Continuous Threat Exposure Management to Reduce Cyberattacks," Jonathan Nunez, Pete Shoard, Mitchell Schneider, 16 July 2025}