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.
We do not describe this work in the abstract. We applied it to our own product, in public — the logbook is in Portuguese.
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 per requirement, not general impressions
- 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
- Conformity plan and engineering sequence
The list of requirements is in the regulation. The value is in knowing what order to solve them in, because doing it 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 the assessment body actually reads, and without which 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
- 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
the proof: this site's own security.txt is the embryo of what we set up for products
What we do not do. We do not run penetration tests against production environments. The work takes place in development and pre-production environments, on material provided by the client.
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