AVANOAvano
Device security

Device Security: know which device you are talking to, and what it runs.

Device Security is identity, firmware trust, attestation and recovery for connected equipment, through the same library. Each is built in software; where a proof needs a hardware root of trust, that root is the maker's board, and the page says which.

01: Built

What exists of Avano Device Security today.

Device identity

Each device has its own identity, made on the device.

Built
One credential for people and machines

Since 5 November 2026 a person, a device, a vehicle or an autonomous system can carry one kind of credential: who or what it is, its unit, and the commands it may give, issued by an authority and handed on with fewer rights, every step checked offline by each device that relies on it. A device obeys only the commands such a credential gives, and only within its own unit, and the authority can withdraw a credential before it ends, with everything delegated from it.

Built
Firmware trust

An image is checked against the maker's signed release before it is trusted: the same verifier built for Avano's own releases. Since 5 November 2026 a device can also demand that the release is in the maker's own public, append-only release log, so a build signed for one device alone is refused. The device keeps the log as one history: a different version of it, shown later, is refused. Independent witnesses can countersign the log, and a device can require that several it chose saw the same history; since 6 November 2026, also that they come from different operators or countries, as the device's own policy says. A device also refuses a release older than the one it accepted, even one its maker signed and logged, unless the maker publishes it again. Where the equipment has a counter in hardware, a copy of the device's storage put back from before an update is refused too, so the older release cannot return that way. Since 6 November 2026 the same holds for the models a device loads, all of a model's files at once: a file added beside it, removed or changed is refused, and the device's software can load the exact bytes that were checked. A release can also name the boards each image is for, and a device that knows its board refuses an image signed for another.

Built
Attestation

A station can ask a module which software it runs and how many times it has been opened, and the module signs its answer; where the maker's hardware keeps the key for a verified start, that answer is proof. Since 6 November 2026 the same answer can also be given as an Entity Attestation Token, the standard form attestation services already read, signed with both a classical and a post-quantum key.

Built
Revocation and recovery

A station can withdraw a permission over the radio, and a net's operator can remove a captured device. A device that is wiped or replaced is rebuilt from a backup only when the backup is its own and its newest, as the other devices that witnessed its record confirm; the replacement then carries the record on, and a copy of the old device that goes on writing is refused by them.

Built
Component provenance

Since 6 November 2026 a part can carry its history from its maker: the maker's signed record of making it, each handover signed by the giver and accepted by the receiver, and for each hand whether it was the maker, a distributor the maker authorised, a supplier the buyer approved, or anyone else. A part that is itself a device confirms with its own key that it was there at each handover. A unit's maker records which parts it fitted, and at delivery the unit is checked against that record; at an inspection, a part that is itself a device answers a fresh challenge with its own key, so its genuine label copied onto a part without that key is shown. A part sold to two buyers is shown by the seller's own signatures. A record names a part; it cannot prove that the object in hand is that part.

Built
A device-trust profile

Since 4 November 2026, all of the above written as one specification a maker can implement against: fifteen requirements, each naming the call in our library that meets it and the test that measures it; since 6 November 2026 its second version, twenty-seven requirements, among them updates trusted only when logged, witnessed and never older, images taken only for the board they were built for, models checked as all of their files, and a written policy over every right. Its third version, the same day, adds a device's answer in the standard attestation format, checked under the post-quantum key fixed when the devices paired, and the rule that nothing is sent because something arrived. Identities are post-quantum from creation, and trust is pinned when two devices pair, never inherited from a certificate hierarchy. It is not a certification.

Written
02: Next

What we build next, with no hardware.

Nothing further without hardware: the next step is the profile on a maker's board.

03: Needs

What it still needs, and from whom.

A board with a TPM or a secure element for each hardware root of trust. Secure boot itself is the maker's.

04: Status

Avano Device Security: built in software.

Pre-release. Built and tested in our own laboratories: not deployed with any customer, not audited by a third party and not certified. The engineering record behind every line here is in the source, under docs/CORP/DEFENCE-INTELLIGENCE-LINE-2026-10-29.md.

All products: Products. Who they are for: Industries. How they are checked: Trust.