Who patches your robot at 3 a.m.

The Brain datasheet carries a specification row that reads, in full: firmware signing keys, held by the customer. The Brain Kit page says it at more length — signed, per-unit keys, customer-held signing keys — beside a row saying the vendor's cloud is unreachable from the body. Every one of those rows is a design target on a product in development, not a measured value on a machine, and both pages say so. We published them before a customer asked. Then we went looking for the procurement document that required them, and could not find one.

An unbounded negative is worth nothing, so here is the bound. Across six instruments read in full, a seventh read only at one remove, three published procurement documents and the EU's tender corpus, searched on 11 September 2026 with the queries and counts below, nothing we could reach requires a supplier to hand the customer the firmware signing key. The seventh is MDS2, which is paywalled: we read one manufacturer's completed form in its place, and the figure below puts it among the documents we did not read rather than among the six. The corpora we could not search: Singapore's GeBIZ, the US federal award system, the ISO and IEC families.

The buyer's question is not whether that row is nice to have. It is: if I hold the key, who patches this thing when something is actively wrong with it at three in the morning?

The defect class behind that question is published, and three of its properties sit in the US National Vulnerability Database, read there on 12 September 2026. Firmware integrity decided by a checksum rather than a signature: CVE-2025-45467, an update path that "implements an insecure verification mechanism that solely relies on MD5 checksums for firmware integrity validation". Decryption material shared across a product line: CVE-2024-52331, a "deterministic symmetric key" for firmware updates, with which "an attacker can create and encrypt malicious firmware that will be successfully decrypted and installed by the robot". An update and control path terminating at the vendor: CVE-2025-2894, an undocumented backdoor that "can enable the manufacturer, and anyone in possession of the correct API key, complete remote control" through the vendor's own remote-access service.

Nothing here says what any of those records' patch status is today. In each of them, what decides whether a firmware image is genuine sits with the vendor, and so does the path an image travels to reach a machine. A companion piece reads that record record by record; this one carries no counts from it.

Start with the concession, because the tempting version of this article is false. One regulator does ask who holds which key. The FDA's premarket cybersecurity guidance, issued 3 February 2026 and non-binding on its own terms — every page of it is headed "Contains Nonbinding Recommendations" — asks a manufacturer to document the custody of every credential, manufacturer- and facility-controlled assets alike. It asks. It prescribes no answer.

The argument is not that nobody thought about this. Nothing in force requires customer-held signing keys, and the reason is not neglect: NIST wrote the split in 2018, and holding the key collapses it. What follows is a reading of published documents by an engineering company, not legal advice. We have measured nothing on a machine, and nothing here runs on a customer site.

What the estate requires

The UK's Product Security regulations, SI 2023/1007, are the usual floor for connected products. Schedule 1, read on 11 September 2026, carries three security requirements: passwords, a place to report vulnerabilities, and publication of the defined support period. Paragraph 1(2) requires passwords to be "unique per product" or "defined by the user of the product". Then paragraph 1(4), in full, because the exclusions are the point:

"In this paragraph, passwords do not include— (a) cryptographic keys; (b) personal identification numbers used for pairing in communication protocols which do not form part of the internet protocol suite; or (c) application programming interface keys."

The law defines a cryptographic key — "data used to encrypt and decrypt data" — and then says the password rule does not apply to it. Searched in full for signing, signature, integrity and authentic, Schedule 1 returns nothing outside paragraph 1's own definitions. It does not reach the update mechanism at all. We did not search the PSTI Act 2022, the statutory guidance, or any enforcement decision.

The international baseline is sharper than silence. ETSI EN 303 645 V2.1.1, provision 5.3-10, requires that "where updates are delivered over a network interface, the device shall verify the authenticity and integrity of each update via a trust relationship". Provision 5.4-4 requires any critical security parameter used for those checks to be unique per device — and its worked example names the holder:

"EXAMPLE 6: The device uses the manufacturer's public key to verify a software update. This is not a critical security parameter and does not need to be unique per device."

So the trust anchor is not left unspecified. The standard assumes the manufacturer holds it, and writes that assumption into a carve-out from its own rule. Searched in full for trust anchor, signing key and key management, no provision assigns the anchor to the customer. We did not fetch ETSI TS 103 701, the conformance test specification, where a test case would live.

One instrument places an actual patching duty, and it is American and medical. FD&C §524B obliges a sponsor to "make available postmarket updates and patches" for known vulnerabilities on a regular cycle and, "as soon as possible out of cycle, critical vulnerabilities that could cause uncontrolled risks", and to file a software bill of materials. Congress put the three-in-the-morning duty on the device's sponsor, which in practice is its maker. Note the verb: make available, not install, not deploy. Searched in full: signing 0, cryptograph 0, key 0. It is also the vocabulary a hospital CISO has internalised, for a class of machine we are not in: a cleaning or delivery robot is not a medical device, and the FCC's own robot definition excludes items classified as devices under FD&C §513 [background — carried forward from an earlier pass, not re-fetched here].

Singapore's CLS(MD), launched 16 October 2024, is voluntary; its four levels run from baseline requirements up to independent third-party binary analysis, penetration testing and security evaluation. Nothing in the published level descriptions or scope asks who holds the signing key. That is all we can say. The technical requirements specification is not on the page we read, and we did not locate it.

Then the hospital's own question set. MDS2, the disclosure statement a buyer sends a device vendor, runs to roughly 240 questions across 23 security capability categories [secondary — ANSI/NEMA HN 1-2019 itself is paywalled and unread]. Stein, Pilgermann and Sedlmayr, who parsed 209 completed statements and 161 white papers, open by noting that MDS2 documents "are rarely integrated into cybersecurity workflows"; 367 distinct ports turned up across the devices they analysed, approximately 40% of them using more than 20.

Since the standard is paywalled we read a completed MDS2 instead, published by a device manufacturer and stated on its face to be based on ANSI/NEMA HN 1-2019, read 12 September 2026. Twenty pages, twenty-three numbered sections, and signing key, code signing, private key, key management, key custody, escrow and root of trust zero times between them.

Its upgrade section asks, component class after component class, whether the owner or operator can install patches, whether the device "require[s] vendor or vendor-authorized service" to install them, and whether the manufacturer allows third-party security updates to be installed "without approval from the manufacturer". Two integrity questions ask whether the device has a mechanism — "release-specific hash key, checksums, digital signature" — establishing that installed software and updates are manufacturer-authorized, and a third asks whether the owner or operator can check integrity at all. The form asks who may apply an update, over and over, and never who may sign one. One completed form is not the standard, and if a question we did not see asks about signing-key custody we would still not know. The hole is narrower than it was.

Which brings the turn. The same non-binding FDA guidance asks a premarket submission to contain

"A precise, detailed list of how each type of credential (e.g., password, key) is generated, stored, configured, transferred, and maintained, including both manufacturer- and healthcare facility-controlled assets (e.g., key management and public key infrastructure (PKI));"

It also asks for a view of the end-to-end update path, warning it "will likely include traversing technology that the device manufacturer does not control". Searched in full across its sixty-four pages: signing key 0, code signing 0, root of trust 0, secure boot 0, key custody 0. The estate regulates the password and, in one sector, asks the custody question in terms. No instrument in it answers.

Who holds the firmware signing key

Instruments

• UK PSTI, SI 2023/1007, Schedule 1Three requirements: passwords, a reporting address, a published support period. Paragraph 1(4)(a) excludes cryptographic keys from “passwords”.
• ETSI EN 303 645 V2.1.1Updates must be verified for authenticity and integrity (5.3-10). EXAMPLE 6 names the manufacturer's public key as the exemption (5.4-4).
• §524B, 21 U.S.C. §360n-2Make postmarket updates and patches available, on cycle and out of it; file an SBOM. signing 0, cryptograph 0, key 0.
• 10 U.S.C. §4401Severable major system components, incrementally added, removed or replaced. signing 0, cryptograph 0, key 0, firmware 0.
• Singapore CLS(MD), from 16 October 2024Voluntary; four levels, up to third-party binary analysis, penetration testing and security evaluation. Nothing published on key custody.
• FDA premarket guidance, 3 February 2026Asks how each credential is generated, stored and maintained, manufacturer- and facility-held alike — and prescribes no answer. signing key 0, code signing 0, root of trust 0, secure boot 0, key custody 0.

Procurement

• HSCC model contract language v2, 53 pagessigning key, code signing, key management, key custody, escrow, private key, root of trust, secure boot: 0. cryptographic key once, in the definition of Data.
• ENISA hospital procurement guidelines, 51 pagescryptographic key, key management, escrow, signing key: 0. patch and its inflections 23, firmware 2.
• A rail operator's supplier requirements, 32 pagessigning key 0; cryptographic key 8, all of them algorithms, cryptoperiods or the glossary; escrow 1.
• TED, the EU tender corpusNine customer-held-signing-key formulations: 0. Controls on the same endpoint: firmware 2,927, penetration testing 333, secure boot 74, software bill of materials 26, code signing 24.

Not read

• MDS2 — roughly 240 questions, 23 categoriesThe standard is paywalled and unread, so no negative is drawn from it here. One manufacturer’s completed form, based on ANSI/NEMA HN 1-2019 and read 12 September 2026, is in the text instead.
• Singapore's GeBIZNo full-text interface, documents behind a login — our own market, unsearched.
• SAM.gov, the US federal award systemNot searched.
• The ISO and IEC familiesOur tooling could not reach them; nothing here is quoted, characterised or attributed from any of them.

Nothing inside this boundary requires an answer. One instrument asks the question.

• Read in full on 11 September 2026 — the box says what it reaches
• Could not read, so no negative is drawn from it

Where the right to modify is law, and where the anchor sits

One body of law gives a buyer the right to modify what they bought. 10 U.S.C. §4401 requires a major defense acquisition program to use an architecture allowing "severable major system components and modular systems… to be incrementally added, removed, or replaced", and to comply with the statutory technical data rights. Searched in full: signing 0, cryptograph 0, key 0, firmware 0. The right is architectural and contractual: a US combat platform must be replaceable by its owner, and nothing says its owner may sign anything.

The anchor's position was fixed by NIST in May 2018, in SP 800-193, §3.5:

"Authorization, however, is the permission to perform an update. While authentication is typically rooted in the device or system manufacturer, authorization to perform updates is typically rooted in the device or system owner."

We searched all 45 pages for the word "owner". It occurs once, and that is the occurrence. The document defining how platform firmware stays trustworthy gives the machine's owner one sentence, and that sentence hands the owner the permission half. §4.2.1.1 follows: each update image "shall be signed by an authorized entity – usually the device manufacturer, the platform manufacturer or a trusted third party". Three entities, and the customer is not one. So the question is not why nobody complies with a requirement for customer-held keys. It is who these baselines were written for, and NIST answered that eight years ago.

The rest of the negative, all read 11 September 2026. HSCC's Model Contract-Language for MedTech Cybersecurity version 2, November 2025 — the US healthcare sector's own model procurement contract, 53 pages — returns zero for signing key, code signing, key management, key custody, escrow, private key, root of trust and secure boot; cryptographic key appears once, in the definition of "Data", as something to protect. It runs a whole patching regime in which who signs is never raised.

ENISA's Procurement Guidelines for Cybersecurity in Hospitals, February 2020, returns zero for cryptographic key, key management, escrow and signing key; patch and its inflections appear 23 times, firmware twice, both in one entry calling missing firmware update procedures "a top threat for healthcare organisations and namely hospitals". A rail operator's supplier cybersecurity requirements of 8 March 2019 return zero for signing key, and their eight uses of cryptographic key are algorithms, cryptoperiods and the glossary entries defining those two terms.

The EU's tender corpus went through TED's full-text operator the same day. Nine formulations — "firmware signing key", "customer-held signing key", "signing keys held by", "customer shall hold the signing" among them — return zero. "signing key" alone returns one, a 2017 airport construction award in whose notice text the phrase does not appear, so the operator is matching fuzzily, which makes the zeros more conservative rather than less. Positive controls on the same endpoint: firmware 2,927, penetration testing 333, secure boot 74, software bill of materials 26, code signing 24. A negative from an untested search engine is worthless; those controls are why this one is not.

Now the holes, as holes. We could not read the MDS2 standard itself, only the completed form above, and we could not locate the CLS(MD) requirements specification. GeBIZ has no full-text interface and keeps its documents behind a login, so Singapore, our own market, is unsearched. We did not search SAM.gov. UK Contracts Finder returned releases for every term we tried, so we could not establish its matching semantics and draw no negative from it; we did not obtain the NHS DTAC assessment form, and draw none from that either. The ISO and IEC families our tooling could not reach at all, and nothing here is quoted, characterised or attributed from any of them.

The bill

The most customer-controlled secure-boot scheme we found in open robotics is ArduPilot's. We surveyed no field: it is what we located on 11 September 2026, a search result rather than a ranking. Its README names the cost in the same breath as the capability. A bootloader carries up to ten public keys; the firmware is signed with one private key; firmware matching none of them does not boot. Then this:

"Note that this will include the 3 ArduPilot signing keys by default as well as your key. This allows the core dev team to help users who make mistakes during the secure boot setup process and prevents issues with vendors who can no longer provide firmware updates to users. If you have a very good reason for not including the ArduPilot signing keys then you can pass the option --omit-ardupilot-keys to the build_bootloaders.py script mentioned above."

Two stated reasons, and both are the bill: the recovery path and the abandonment path. The same README gives the consequence of getting it wrong — "with a secure bootloader and an unsigned firmware the board will stay in the bootloader forever as it will be failing the secure boot checks." That is ArduPilot's published description of ArduPilot's own scheme, quoted as theirs.

What follows is our reasoning, not anyone's measurement. The distinction matters, because we went looking for the measurement. There is no published mean time to patch under customer key custody. No case study of an incident delayed by a key-holder's availability. We will not invent either.

The constraints are four. An out-of-hours fix needs the customer's signer reachable and authorised [inference]; the nearest published support is §524B's out-of-cycle duty, which rests on the manufacturer while the signing capability does not. The supplier's ability to respond is bounded by the customer's roster rather than the supplier's [inference]. Losing the key is losing the fleet unless a recovery path exists — ArduPilot's stuck bootloader, and NIST §3.5.1's "proper use of signatures thus necessitates provisions to recover from a key compromise". Any recovery path is a second trust anchor, which is NIST's point rather than ours: its examples run from key hierarchies to updating the key store while updating the image.

Two industries with nothing to do with each other have answered that fourth constraint, and both said escrow. The rail operator asks a supplier to "provide a contingency plan for the security of the procured solution in the event the Supplier leaves the business (e.g., security-related procedures and products placed in escrow)". The FDA's non-binding guidance recommends manufacturers "establish and maintain custodial control of device source code… through different methods, such as source code escrow or source code backups", its footnote defining escrow as a deposit with "an independent third party ('escrow agent')". Both put a third party between the buyer and the code. Escrow is a second trust anchor under another name, and so are ArduPilot's three default keys.

The mirror image has a date on it. Microsoft's Windows secure boot certificate page, last updated 18 May 2026, gives expiries for Microsoft Corporation KEK CA 2011 on 24 June 2026, Microsoft UEFI CA 2011 on 27 June 2026 and Microsoft Windows Production PCA 2011 on 19 October 2026, after which devices that have not taken the 2023 replacement certificates "will no longer be able to receive new security protections for the early boot process". A key held by one party for a planet's worth of machines expires on a published date. Both custody models have a three in the morning. The question is whose phone rings.

The clock is already running. The Cyber Resilience Act's Article 14 duties, including a final report due no later than 14 days after a corrective or mitigating measure is available, have applied since 11 September 2026 and reach machines already sold — an argument made elsewhere. The asymmetry is one line. The duty to report runs on the supplier's clock; the ability to make a fix reach a fleet runs on the key-holder's.

Every cell above is either a quotation from a published document or an inference from the arrangement, marked as one. Not one is a measurement, and there are none to cite. The columns are the general case and describe nothing we operate: Tidewell holds no customer's key today, the first Brain Kit is in design, and the customer-held signing key on our datasheets is a design target on a product in development, not an operating practice.

Sources, all read 11 September 2026: NIST SP 800-193, May 2018, §3.5, §3.5.1 and §4.2.1.1; 21 U.S.C. §360n-2; the ArduPilot secure-boot README; Microsoft's Windows Secure Boot certificate page, updated 18 May 2026; Regulation (EU) 2024/2847, Article 14(2), with Article 71(2) fixing the application date.

What we owe a customer, and have not written

We read the three de-vendoring vendors we could find, all on 11 September 2026. Movel AI in Singapore sells retrofits for "multi-brand robots with outdated software"; its own case study ends with a rescued fleet "linked… up with our cloud-based FMS", and the offer includes remote support. Movel replaces one vendor's cloud with its own. Alias Robotics sells a "Robot Endpoint Protection Platform" defending the stack a robot already runs — telemetry, signing, cryptograph, key, isolation, firmware, cloud, vendor and replace appear zero times on that page. Palladyne AI describes platform-agnostic software and claims nothing about firmware, keys, provisioning or telemetry [single source — the vendor's own page, read through a summariser because the host blocks direct fetch].

We found no vendor selling all three of telemetry removal, provisioning replacement and a customer-held update path, and each of the three selling one says in writing that it does not do the other two.

Our own pages say what they say, and the limit is printed beside the promise. From the Brain Kit page, verbatim:

"The safety case for a retrofitted body is an independent supervisory controller plus network isolation. It is not a certified body. We do not control the vendor's low-level firmware, and the datasheet says so."

Every row in that specification table is a design target; kit mass, power draw and installation time are not yet budgeted from an engineering record, and the page says so.

Which leaves the part we have not written. A customer-held signing key is a design position on our side, not an operating practice: the first kit is in design, nothing runs on a customer site, and the arrangement on the other side of the commitment — who signs, how that person is reached out of hours, what a customer does when they cannot be — does not exist. We have not written it, and it is not a document we are withholding. A buyer reading this will notice, and should.

We do know the shape any answer has to take. NIST's split is the default the world runs on, escrow is the world's published answer to abandonment, and both recovery paths hand trust to a third party. Any arrangement we write is a choice among those three — the split as NIST drew it, escrow, or default upstream keys — and the honest thing to say today is that we have not made it.

The question stands as the buyer asks it, and it is the right one to put to us and to anyone selling a machine that updates itself. If I hold the key, who patches this thing at three in the morning?