An open operating system for machines you own

Every connected device makes claims about itself. This firmware is genuine. This update came from the vendor. This key never leaves the chip. This data stays on the device. Most of those claims are made by software the owner cannot read, signed by keys the owner does not hold, and verified by processes the owner cannot inspect. The owner is asked to trust the claim because the vendor said so.

That is not a trust model. It is a reputation model, and it fails exactly when it matters: when the vendor is wrong, compromised, acquired or gone. A claim about security that cannot be checked by the person relying on it is not a claim. It is an assertion. For machines that will run agents, hold keys and act on their owners' behalf, the distinction stops being academic.

Regulation now asks for evidence

The European Union's Cyber Resilience Act, Regulation (EU) 2024/2847, entered into force on 10 December 2024. Its reporting obligations have applied since 11 September 2026, and its main obligations apply from 11 December 2027 (European Commission). Manufacturers of products with digital elements must handle vulnerabilities over the product's lifecycle, and some products of particular cybersecurity relevance need third-party assessment before they can be sold.

The reporting regime is already live. A manufacturer that becomes aware of an actively exploited vulnerability or a severe incident must send an early warning within 24 hours and a fuller notification within 72 hours. A final report follows no later than 14 days after a fix or mitigation is available for a vulnerability, or within one month for a severe incident. Notices go simultaneously to the national CSIRT and to ENISA, through ENISA's single reporting platform (McCann FitzGerald).

Think about what that timeline demands. To report an exploited vulnerability within a day, a manufacturer has to know what is in its product, what it depends on and how it behaves. To fix it within the lifecycle, it has to be able to change it. Opaque, inherited components are a liability under that regime, not a shortcut.

Europe already distinguishes publishing from selling

The Act treats free and open-source software deliberately. It creates the role of an open-source software steward: a legal entity that provides sustained support for the development of open-source products intended for commercial use. Stewards must put in place a cybersecurity policy for secure development and vulnerability handling, cooperate with market surveillance authorities and report actively exploited vulnerabilities and severe incidents. Under Article 64(10), they are not subject to administrative fines for infringements of the Act (European Commission).

The policy logic matters. The law accepts that publishing code openly, so that anyone can read and build on it, is different from placing a product on the market. Responsibility sits with whoever sells the product. The open layer underneath is something the whole market can inspect, and the steward's job is to keep it healthy.

Ownership is becoming a legal right, not a setting

A second line of European law points the same way. The Data Act became applicable on 12 September 2025, giving users of connected products the right to access the data those products generate. Since 12 September 2026, products placed on the market must be designed so that users can reach that data directly and by default, where relevant and technically feasible, in a structured, machine-readable form (Matheson).

Taken together, the two laws describe a device the owner can understand and get data out of, with a manufacturer accountable for its security over time. That is very hard to deliver on a stack where the important parts are closed.

Trust roots held by someone else

Consider where a typical machine's trust actually comes from. On most PCs, the chain that decides which software may boot runs back to certificates held by an operating-system vendor. Microsoft's 2011 Secure Boot certificates expire through 2026: the KEK CA on 24 June, the UEFI CA on 27 June and the Windows Production PCA on 19 October (University of Wisconsin; Microsoft). Most devices receive the replacements automatically through Windows Update; some older systems need firmware updates from their manufacturers.

Nothing in that is a scandal. It is a well-run rotation. But it shows who holds the root of trust on a machine you bought: not you. Owners depend on a vendor and a device maker, acting in coordination, to keep their own hardware trusting the right software. For a laptop that is an acceptable bargain. For a machine that holds an agent's keys, controls a building or runs a city district's services, it is a dependency worth questioning.

Hardware keys, open code

The alternative has two parts, and both are needed.

First, authority lives in hardware the owner controls. Keys are generated and held in a security chip and never exist as files that can be copied. Identity, signing and the decision about what a machine will run all trace back to those keys. Whoever holds them owns the machine in the sense that matters.

Second, everything that makes a trust claim is open. The boot chain, the code that uses the keys, the update mechanism and the policy that decides what runs can all be read, built and checked by the owner, an auditor or a regulator. Closed components may still sit on top, but nothing that asserts security does.

Open code without hardware keys gives you transparency without control. Hardware keys without open code give you control you cannot verify. Together they give an owner a claim they can check and a machine that answers to them.

What this means for researchers

Treat inspectability as a property to measure, not a slogan. Which components of a system make security claims, and which of those can a third party reproduce from source? How much of the trust chain depends on keys outside the owner's control? These are questions with answers, and they would make useful benchmarks for edge and device platforms.

What this means for policymakers

The Cyber Resilience Act and the Data Act already reward this design. Two steps would sharpen it: prefer, in public procurement, devices whose trust-relevant code is published and buildable, and recognise owner-held hardware keys as evidence of control in conformity assessment. Both would make security claims cheaper to check and harder to fake.

What this means for CTOs

Inventory where your machines' trust comes from. For each class of device, write down who holds the keys that decide what boots and what is updated, and whether you could rebuild the trust-relevant software from source. Plan your CRA reporting process around components you can actually see into. Anything you cannot read, you cannot report on in 24 hours.

Where Praecise fits

Furcate is the open-source operating system and leaf firmware that Praecise develops and stewards at furcate.org, licensed Apache-2.0. Everything that makes a trust claim is open, and so is everything a person needs to build a private, local AI system of their own on boards they can buy. Praecise Furcate adds Furcate Leaf, Node and Hub hardware designed by Praecise, cells at home, business and city scale, each a cluster with its own control and authority held in hardware keys, plus tuned system images, optimised model serving, fleet operations and support. Infrastructure owners can operate machines, data centres and edge cells on it.