Services
We help take a product from the state of prototype that works to the state of product that can be sold in Europe safely. The hardware is the vehicle. The real work is conformity, security engineering and the documentary evidence the CRA demands.
A first read, at no cost and in writing
Describe your product to us by email, what it is, what it does, how it connects and what stage it is at, and within five working days we send back a written technical note, two pages long, with four things: the product's likely classification under the CRA and the reasoning behind it, the conformity assessment path that follows from it, the three most urgent decisions for that specific product, and the regulation's dates that apply to the case.
No call and no meeting. No commercial follow-up unless you ask for it. The note is a sample of our work, and if it proves useful you know where to find us.
To be clear from the start. The read is based solely on the information you send us. It is not an audit, not legal advice and not a conformity assessment. Do not send code, credentials or confidential documentation; a functional description is plenty.
To request one: oi@folhas.io with the subject "First read".
The work from there
- CRA conformity analysis
The starting point for any connected product is understanding where it stands against the Annex I requirements and what it is missing. The report goes requirement by requirement, with the state of each one, the evidence behind it and the nature of the fix.
- Every essential requirement of Annex I assessed against the real product
- Concrete evidence for each requirement
- The nature of each fix identified, whether code, infrastructure, process, manufacturing or documentation
the proof: the full audit of our own prototype, with every flaw in plain view
further reading: the CRA guide for manufacturers · classifying the product
- Conformity plan and engineering sequence
It sets the order in which to solve the regulation's requirements, because solving them out of order means doing work twice.
- The sequence from prototype to product, with phases and dependencies made explicit
- A cost model that includes the part of the work that is not code
- Manufacturing, infrastructure, documentation and the organisation in the same plan as the firmware
the proof: the four-phase plan applied to our own product, and why much of the effort is not firmware
- Firmware and system security engineering
The concrete technical fixes, done in the order the devices' identity architecture imposes.
- Device identity, a key authority, and first boot with a per-unit secret
- Signed and verified OTA updates, and encrypted, authenticated communication
- Verified boot and secure data erasure at end of life
the proof: the technical logbook entries, as we solve each item on our own product
- Documentation, SBOM and conformity assessment
The part a market surveillance authority can demand, and that a notified body reads when the assessment path requires one. Without it, a secure product still stays off the market.
- An SBOM generated at build time and archived per release
- Annex VII technical documentation and security instructions for the user
- The process that underpins the CE marking
the proof: the SBOM and support-period decisions of entry 001, taken before there was a product
further reading: SBOM for embedded firmware · the support period
- Coordinated disclosure and vulnerability response
The channel, the policy and the response process, set up before the first vulnerability appears.
- security.txt, a PGP key and a coordinated disclosure policy
- A triage and response process with named owners
- The Article 14 notification templates, rehearsed before they are needed
further reading: coordinated disclosure · the 24 h and 72 h notifications
Offensive assessments
We come from pentesting and red teaming, and that is the eye we bring to products. These assessments are the same craft, with scope, authorisation and rules of engagement in writing before anything happens.
- Whitebox pentest of firmware, systems and applications
With access to the code, the binaries and the architecture, we follow the path an attacker would take and show how far it goes. In development and pre-production environments, on material provided by the client.
- Threat modelling and architecture review
Before there is code to attack: the assets, the plausible attack paths and the design decisions that close them, at the stage where they are still cheap.
- Physical intrusion of premises
An authorised attempt to get into the premises and reach a defined asset (a room, a network cabinet, a workstation), with a report of the path taken, what made it possible and the fixes, from access control to how people behave. Four patterns we find, in constructed examples.
What we do not do. We do not run penetration tests against IT systems in production. The technical work takes place in development and pre-production environments, on material provided by the client.
Physical intrusion, to be clear. Only with written authorisation from whoever has authority over the premises, a defined scope, schedule and target assets, an authorisation letter with an emergency contact carried by the people executing it, and rules that exclude damage and any risk to people. The applicable insurance cover is confirmed before every engagement.
On conformity. The declaration of conformity belongs to the manufacturer and is the manufacturer's responsibility. We support the preparation and reduce the technical risk; we do not and cannot guarantee the outcome of an assessment.
Scope and pricing are set by proposal, after a first technical conversation about the product and the stage it is at.
Alongside the consultancy we build Aeromate, our own environmental control ecosystem, which serves as the public case study for all of this work.
Not sure which of these applies to your case? Describe the product and the stage it is at, and we will tell you frankly whether and where we are needed. oi@folhas.io