CRA Product Security Engineering
More than process consulting: the CRA demands product security that holds up what your documents claim
BreachLabz backs your security engineering: take the firmware apart, find the attack paths, build the security in, prove it works. Risk assessment, processes, documentation and conformity come along for the ride, and by the end your team owns all of it.
admin:admin is now a matter for CRA Annex I, Part I (2)(b)
Secure default settings, signed updates, no known vulnerabilities at shipment: these CRA product requirements apply from December 11, 2027. But one obligation is already live, and it does not target your product. It targets you as an organization: the reporting duty.
Since September 11, 2026, manufacturers have had to report actively exploited vulnerabilities and severe security incidents. Early warning within 24 hours, detailed notification within 72 hours, final report after 14 days or one month. Reporting runs through ENISA’s Single Reporting Platform, which forwards to the national CSIRT, in Germany the BSI. This applies to anyone placing products on the EU market, wherever they are headquartered.
The part that gets missed: this is not limited to new products. It covers everything already out in the field, across a support period of at least five years.
And you can only meet the obligation if you know what is inside your product and whether a reported vulnerability actually touches you. That is not purely a process question. That is work on the product, with a process wrapped around it that still holds at three in the morning.
Your product has to be compliant by December 11, 2027.
Your organization has had to be report capable since September 11, 2026.
Not ready? Then that is where we start.
We have already speedrun cybersecurity regulation: BreachLabz for CRA grade product security
The CRA is new territory for most manufacturers. For us it is the second run. UN R155 and ISO/SAE 21434 pushed the automotive industry through the same eye of the needle years ago: proof obligations across the lifecycle, vulnerability management, risk assessment, documentation that survives an audit.
With years of hands on experience across the global vehicle supply chain, which reaches into nearly every other industry, we have already shown what we can do. We know the walls manufacturers are about to hit, and we know from project reality how to get through them.
Soldering iron, not slide deck
Around 100 pentest projects on real hardware, for well known clients worldwide, always against the clock. We would rather talk about findings than customer logos. People know us.
Firmware reverse engineering, hardware attacks, fault injection, secure boot, update paths, backends and interfaces. Plus risk assessment and SBOM tooling.
Team and pentest lab in Munich and Bangalore. Short paths, no handoff chain, no junior swap in after kickoff. Whoever wins the project runs it.
How working with BreachLabz on the CRA actually looks
Four principles that separate our projects from classic consulting: we ship code instead of documents, we move at your pace, we speak both tech and regulation, and we bring along everything other people have already gotten wrong.
In the repo, not in the meeting
We work in your Git, build the firmware ourselves and open pull requests. No handover documents. The result runs on Monday instead of sitting in a PDF.
On your team’s clock
We work in your sprints, with your toolchain, without imposing a new process first. “Security is slowing us down” is what kills projects from the inside. We disprove it.
One person, both languages
Your contact talks bootloader partitions with firmware engineering and Annex VII with regulatory affairs. No translation layer. That shortens everything.
We know where others broke
We know what makes secure boot defeat entire teams, how suppliers react when a vulnerability lands in their inbox, and what no standard will tell you. That convinces people more than a list of certificates.
BreachLabz Security Engineering: we run alongside your product development, to CRA spec
So we work directly on the device. We pull the firmware, reconstruct what is actually in there, cross check against known vulnerabilities and test whether an attack really lands on your specific product. Then we support remediation and retest every fix.
Test real risk. Not checkboxes.
The CRA starts at the product. Not at a PDF. A sizeable market is forming around it right now: maturity models, measure catalogs, checklists with thirteen tick marks. None of those documents answers the question that counts when it counts. Is my product attackable, and if so, how exactly?
Whatever you already have, we put to work: we inventory existing evidence and measures, map them to the CRA requirements, and close the gaps that are genuinely left. Usually that is far fewer than the going CRA consulting pitch would suggest.
A pentest does not trigger a reporting obligation under Article 14. Only actively exploited vulnerabilities and severe incidents are reportable, not findings from testing or security research. Testing does not create regulatory risk. It lowers it.
./cra --scope=your_product --mode=hands_on
Four ways in. Bookable separately, built to connect. Where you start depends on what you already have. What you walk away with is always the same: a product you actually understand, evidence an assessor can read, and a team that can keep it running without us.
Who reports what, and when, settled before anything catches fire
For everyone who has been under the reporting obligation since 09/2026 and still does not know who decides what, when. We assess your status quo, define trigger criteria, escalation path and authority, and deliver reporting templates for every deadline. We sort out access to the ENISA platform and run the real thing as a tabletop exercise.
Plus the CVD policy with a public reporting channel, the one process document the CRA names outright. How much you run yourselves and how much we run, we settle together.
Deliverables: reporting process, role model, templates, CVD policy, exercise report
From gut feeling to CRA roadmap: classification, risk, gap analysis
For everyone who first needs clarity on CRA exposure and effort. We assess and classify your products, recommend the conformity assessment route, define the product boundary and produce the cyber risk assessment and gap analysis against Annex I.
We use what is there: an existing risk assessment gets reviewed for CRA robustness, what is missing we build with fitting methodology and tooling. For legacy products we clarify what is due by 12/2027 and what only kicks in on substantial modification.
Deliverables: scoping, classification, risk assessment, gap report, prioritized roadmap
We x-ray your product and show you which vulnerabilities actually hit you
For everyone who is not sure what is inside their product. SBOM and HBOM from the actual artifact: binary and source analysis, cross check against known vulnerabilities, assessment of real exploitability in your product context, CRA grade risk picture.
We set the depth together: the CRA requires at minimum the directly integrated components, while vulnerability management often benefits from going deeper. What we could reconstruct and what we could not is stated in the report, not hidden between the lines.
Deliverables: SBOM (SPDX/CycloneDX), CVE matching, exploitability assessment (optional VEX), risk picture, build integration
From architecture through pentest to running vulnerability operations
For everyone actively working on product security: requirements, architecture, secure boot, update and rollback paths, remediation. We develop alongside you or guide your team, always so that you can carry it afterwards: documentation developers will actually read, ownership as a project goal.
Plus our core: pentest and product security analysis with fix retest and test report. Then the long run: vulnerability monitoring, triage, reporting support, with your tooling or ours, reachable when it is burning.
Deliverables: requirements, design, test reports, Annex VII documentation, ongoing vulnerability handling
None of this fits your CRA needs?
That is CRAzy. We also work piecemeal, as reinforcement for your team or as a named role for a fixed stretch. Talk to us.
How a CRA project with BreachLabz gets started
Why BreachLabz?
Frequently asked questions
Does my product even fall under the CRA?
Rule of thumb: if a product processes data and can connect to a device or network, directly or indirectly, then in case of doubt it is a product with digital elements (PDE). A pure SaaS service without a local component is not, that may fall under NIS2 instead. An app that does not work without your backend is, together with that backend, one product. We settle it in the exposure assessment.
We have been under the reporting obligation since 09/2026 and have no process. How bad is that?
Bad enough to start now, not bad enough to panic. Report capability requires a defined process, not finished product conformity. That can be stood up in weeks. Full conformity by December 2027 depends on the product, which is what the gap analysis is for.
Is BreachLabz a notified body?
No, and that is deliberate. We test and we build. Conformity assessment by a notified body is a separate step that we prepare and support. For most products in the default category, self assessment is sufficient anyway, with complete technical documentation.
What about our legacy products?
The reporting obligations apply without exception, including to anything placed on the market before the cutoff. The remaining CRA requirements generally only bite on legacy products upon substantial modification after December 11, 2027. What counts as a substantial modification is a matter of interpretation. We document the assumption with you.
Does a pentest trigger a reporting obligation for us?
No. Reportable means actively exploited vulnerabilities and severe incidents. Findings from penetration testing and ethical security research are explicitly out of scope.
Do we have to publish the SBOM?
No. The SBOM is an internal document you present to the market surveillance authority on reasoned request. What you do have to publish is the CVD policy, the route by which outsiders can report vulnerabilities to you.
Which standards does BreachLabz work from on the CRA?
The ones you can actually work with today: BSI TR-03183 as the baseline, the EN 40000 drafts as the direction of travel, ISO/IEC 29147 and 30111 for vulnerability handling. A presumption of conformity only exists once a standard is listed in the Official Journal. Until then we document, requirement by requirement, how your product meets it or why it does not apply.
Does BreachLabz replace our team?
No. We work in the repo, in your sprints, with your toolchain, and the goal of every measure is that your team runs it alone afterwards. If you stop needing us, we will be the ones still waiting on the next console generation.
What does it cost?
Depends on the product, the starting point and the scope. We assemble packages, deliverables and the quote to fit, and after a short call we give you a reliable estimate. The two week entry point is deliberately cut so the decision is an easy one.
Do you work remotely?
Mostly. Hardware comes to our lab in Munich or Bangalore, the rest runs more efficiently remote. On site works too.
Get a quote today!
Send us a few basics. What kind of product is it, what software is in there, where does it sit in the market, and what is pressing hardest right now.
We come back within 24 to 48 hours and tell you honestly whether we are the right fit.
Ready to meet? Talk to us today.