What Hardware Manufacturers Can Learn From OPPO's Vulnerability Prioritization Program

The EU Cyber Resilience Act gives hardware manufacturers a 24-hour window to report actively exploited vulnerabilities to regulators once they're discovered.

For most security teams at device makers, that mandate lands on top of an already-stretched program: firmware assets that are harder to test than web applications, researcher communities concentrated in domestic markets, and remediation workflows that depend on hardware supply chains they don't fully control.

A structured, auditable process for intake, triage, routing, and verification that regulators can actually review is needed. OPPO built that infrastructure. Their vulnerability disclosure program on HackerOne covers over 120 assets across software, firmware, and hardware, and their triage workflow runs from submission to closure in under 30 days on average, with a documented escalation path at every stage.

Why Periodic Testing Isn't Enough

Before OPPO moved to HackerOne, they ran their bug bounty program on a platform they built themselves. It worked well enough for their home market, but as their product footprint expanded internationally, the program couldn't reach the researchers most likely to find their highest-risk vulnerabilities.

In their own words, it was "hard to contact more researchers around the world," and many international researchers didn't know the program existed.

That's a common pattern for device manufacturers. Programs built for compliance check a box, but they don't generate the continuous external pressure that surfaces real risk before attackers do. Testing is periodic, so the gap between what's deployed and what's been formally validated grows quietly while the 24-hour reporting window requires you to know about actively exploited vulnerabilities before they're exploited at scale.

When OPPO moved to HackerOne, they started receiving reports from researchers across Europe, Asia, and the Americas, building the engine for continuous coverage. Volume increased but what matters next is whether the triage and remediation loop can keep pace.

How OPPO Separates Hardware From Software Reports

Their triage teams use a single diagnostic rule to make the call quickly:

• If a vulnerability is reproducible and fixable by reinstalling or flashing firmware, it's a software issue.
• If it occurs randomly, is affected by temperature or physical shock, and can't be resolved by flashing, it's a hardware issue. 

That distinction determines which engineering team owns the report and what the remediation timeline looks like.

For software and web vulnerabilities, OPPO routes by domain or package name. Every business unit owns a set of domain names and package identifiers, and their internal system maps incoming reports directly to the responsible team. Incorrect assignments get flagged and reassigned by the security team.

Hardware and firmware reports follow a different path. OPPO classifies the vulnerability type first, then routes to the corresponding audit team. OPPO has established a comprehensive third-party vulnerability collaborative disclosure and reporting mechanism, actively working with upstream and downstream suppliers to jointly address and remediate vulnerabilities. 

Vulnerability Prioritization: The Decision Logic That Determines What Gets Fixed First

Once a report is routed, two factors drive the prioritization decision: the number of users affected and the sensitivity of the data involved.

• Reports with high user impact or significant data exposure get accepted as priority remediations, with careful consideration given to supplemental factors like CVSS scores. 
• Reports where the affected population is small may be downgraded in severity.
• Reports with low immediate risk go into a monitored backlog with a defined review trigger.

The framework is user-experience-driven by design. As OPPO's security team puts it: "Everything is based on the user experience."

When a regulator asks why a particular vulnerability was handled the way it was, the answer maps to a documented decision about user impact, not a judgment call made under pressure. 

Vulnerability prioritization treated as informal doesn't survive regulatory scrutiny.

The Remediation Workflow That Produces the Audit Trail

After severity is assigned and the report is routed, the remediation loop runs through five documented stages.

The report is synced to the responsible business owner with a remediation SLA set at the time of assignment. If the SLA is missed, the escalation path goes to the business owner's direct supervisor, which means missed deadlines have consequences rather than slipping into a queue.

Once the fix is complete, the business owner confirms it in the HackerOne platform backend. That triggers the second stage: OPPO's security team independently validates the fix before the report is closed. The report stays open until the security team confirms the vulnerability has been fully remediated, not just patched on one model or in one firmware branch.

That two-stage verification loop is what produces the audit trail regulators expect. Every step is timestamped, every assignment is attributed, and the escalation path is recorded. OPPO's average time from triage to bounty payment runs under 10 days against a 30-day target.

Build the Workflow Before the Clock Starts

For most device manufacturers, the honest answer to "show me your vulnerability handling audit trail" involves email threads, spreadsheet trackers, and ticketing systems that weren't built for what the CRA requires.

The H1 Platform produces that audit trail by design, with timestamps, assignment records, verification steps, and closure documentation built into the workflow. It fits around the triage and routing logic your security team already has and formalizes it into something you can stand behind in an audit.

See how your vulnerability handling workflow maps to CRA requirements with HackerOne