The review had reached the point where everybody in the room knew the answer and nobody wanted to say it first. The product worked. The demo units were stable. The firmware team could explain the boot flow, the update path and the field-support story with confidence. Then the customer's security lead asked for the evidence pack: the signed boot-chain record, the vulnerability triage history, the support-period statement, the SBOM tied to the release binary, and the test report that proved recovery after a failed update.
The engineering was real. The evidence was not. It lived in fragments: a wiki page that was one firmware version behind, a build log retained by a CI system nobody trusted for long-term records, a spreadsheet from the certification project, a chat thread where the decisive trade-off had been made. The team had done more good engineering than the file could show. To the reader outside the room, that is the same as not having done it.
This is the shape of the next few years for connected-product teams. The Cyber Resilience Act, PSTI, RED cybersecurity requirements, customer questionnaires, procurement reviews, cyber insurance and acquisition diligence are all asking the same underlying question: show me that the product is trustworthy, and show me in a form I can inspect without borrowing your best engineer for an afternoon.
Most firmware organisations are not culturally ready for that question. They are used to proving truth by demonstration, by failure rate, by the judgement of a small group of people who know the platform deeply. The best teams carry an enormous amount of product knowledge in the heads of senior engineers. That knowledge is often accurate, nuanced and hard won. It is also invisible to the regulator, the customer, the buyer and the board.
The weak response is to treat compliance as a checklist exercise. The team keeps building the product in the old way, then somebody produces documents at the end. The documents say secure by default, signed OTA, vulnerability handling, support period, SBOM. They sound plausible until the first serious reader asks which release they describe, which binary the SBOM came from, what happened to the oldest supported units, where the signing key lives, and whether the rollback path has been tested on hardware rather than sketched in a design review.
A checklist can produce the appearance of compliance. It cannot produce a trustworthy product. It also cannot rescue a team whose architecture made the wrong promise two years earlier. If a device cannot receive a security update safely, the most polished policy in the technical file is only evidence of the gap.
The better response is craft. Not craft as romance. Craft as the disciplined joining of material, method and judgement. Firmware has always been a craft in this sense. The material is constrained hardware, unpredictable networks, factory variation, long support windows and devices nobody will touch again after installation. The method is release discipline, defensive architecture, testing that attacks the uncomfortable paths, and records that survive staff changes. The judgement is knowing which shortcut will merely make the code untidy and which one will make the fleet unmaintainable.
Compliance as craft means secure boot is not a feature claim. It is a chain of custody. A reviewer can see the root of trust, the bootloader verification, the application verification, the signing key, the release record, the manufacturing attestation and the test that proves an unsigned image is rejected. The evidence does not decorate the engineering. It follows the same grain as the engineering.
It means OTA is not a campaign button in a backend. It is a field promise. The device can receive an update, reject a bad one, survive power loss, roll back from a boot failure, report its state, and remain reachable when the long tail of the fleet comes back online months behind the latest release. The recovery path is not an exception. It is part of the product.
It means vulnerability handling is not a public inbox and a policy copied from a larger company. It is an operating rhythm. Advisories are received, matched against a current SBOM, triaged against the actual product configuration, fixed or justified, released, disclosed and retained. The record shows who made the decision, what evidence they used, and which product versions were affected.
TallTree exists because almost nobody is joining these things together for the teams that need it most: connected-product manufacturers with serious firmware, real field obligations and not enough spare time to turn regulation into engineering work. The lawyers can explain the obligation. The test lab can run the test. The certification consultant can tell you how the file should look. The gap is the work between firmware reality and external proof.
That gap is where product trust is won or lost. A connected product can pass conformity assessment and still be fragile in the field. A product can have good engineers and still fail a diligence review because the evidence is scattered. A team can ship security updates for years and still be unable to prove, under pressure, that the supported fleet is actually supportable.
I do not think the answer is more performance around security. The firmware world has enough inflated claims. The answer is quieter and harder: name the product version, write down the decision, tie the evidence to the release, test the path that will hurt if it fails, keep the file alive for the support period, and make sure a competent reader can follow the work without theatre.
That is what TallTree will publish here. Practical writing on CRA, PSTI, RED, secure boot, OTA, SBOM, vulnerability handling and the evidence that regulators, customers and buyers ask for. No breathless certainty. No generic security advice pretending to understand firmware. No legal advice dressed as engineering. Just the work of turning product-security reality into something a serious reader can trust.