Identity of Things in Defence: What NIS2, CRA, and EDF 2026 Actually Require

August 8, 2026 ·Gustav Poola ·

identity-of-thingsdefenceautonomous-systemsdrone-identitymachine-identitynis2craedfadeshardware-root-of-trust

A drone, a sensor pod, or an autonomous ground vehicle cannot produce a signature that a human operator, a supply-chain auditor, or a defence-procurement officer can hold against the deploying organisation unless the machine itself carries a hardware-anchored identity. Chip-anchored personnel identity plus hardware-anchored device identity plus signed telemetry is the load-bearing architecture underneath every credible autonomous-defence deployment — and it is what NIS2, CRA, and the emerging EDF supply-chain requirements are converging on.

Identity of Things in Defence: What NIS2, CRA, and EDF 2026 Actually Require

"Who signs for a drone?" is the question a Nordic defence-tech integrator's chief architect asked us at a recent conversation, after his upstream customer's procurement audit surfaced a gap in his fleet's evidence chain. His forward-deployed sensor pods were producing clean telemetry against a certificate authority they controlled — but the audit asked whether they could walk the evidence back, years later without the deploying operator's cooperation, from a disputed action to the human decision that authorised it. Half the chain was strong (the software-side certificate) and half was assumed (the hardware). This post is that architecture, in the shape a defence-procurement, integration-engineering, or programme-management audience needs.

What is machine identity, and why does autonomous defence need it specifically?

Machine identity is the equivalent of a passport for a hardware device: a cryptographically verifiable claim that a specific physical object exists, is what it says it is, and is under the operational control of a specific organisation. Enterprise IT has used the concept for a decade (TPM 2.0, X.509 machine certificates), but defence demands are sharper — a commercial IoT deployment can tolerate a soft-provisioned certificate in a filesystem; a defence deployment cannot, because the certificate stands between "authorised autonomous action" and "spoofed autonomous action" and the adversary actively probes that boundary.

The authoritative frameworks converge on hardware root of trust plus attestation. NIST SP 800-193 defines platform-integrity requirements; NIST SP 800-207 frames Zero Trust operational model; IETF RFC 9334 specifies how a device produces signed claims about its own state; IEC 62443 covers industrial automation. Together they describe an architecture where the device carries a private key inside a non-extractable hardware secure element, signs attestations against that key at every meaningful action, and can be revoked the moment compromise is detected.

Where I most often see this go wrong in defence deployments: fleets get provisioned with software certificates because it is faster to deploy, then never get upgraded to hardware-anchored identity because "the software certificate works." It does — until the audit or the incident. Then the missing hardware root is why the chain of custody unravels.

Where do NIS2 and CRA actually require this in defence deployments?

Three instruments converge on identity-of-things requirements for defence-adjacent deployments.

NIS2 Directive (EU) 2022/2555 (in force October 2024) extends network-and-information-security obligations to essential and important entities. Article 21(2)(d) — supply-chain security — requires suppliers to meet security requirements demonstrable through evidence. In autonomous-system supply chains, that evidence is exactly the attestation chain a hardware-anchored identity produces. Deeper walk-through: NIS2 Article 21: What Evidence Do You Need?.

Cyber Resilience Act (EU) 2024/2847 (applying December 2027, staggered from December 2026) imposes cybersecurity requirements on products with digital elements — Article 13 + Annex I require unique product identity, secure updates, and cryptographic data integrity; Article 14 adds signed SBOM obligations. Walk-through: CRA + Signed SBOM as Trust Anchor.

European Defence Fund (EDF) 2026 SME calls impose supply-chain-security demonstration on SME consortium proposals. Proposals that cannot demonstrate identity-and-attestation architecture at the device level score poorly on security-and-integrity evaluation. Walk-through: EDIP + EDF: Why Defence Tenders Are Moving to AdES.

Timing matters: CRA obligations begin biting December 2026, EDF 2026 proposals close September 2026, NIS2 audits are already active. Programmes that have not architected for hardware-anchored device identity by mid-2026 will spend late 2026 and 2027 retrofitting under regulatory pressure.

How does chip-anchored personnel identity connect to hardware-anchored device identity?

Every defensible autonomous-defence deployment has to answer two identity questions simultaneously: who authorised this action (personnel identity) and which device executed it (machine identity). The two questions are usually treated as separate architectural problems. In practice they need to be a single chain, because a signed action that cannot be walked back to a verified human decision is not the same asset as a signed action that can.

The personnel side has a mature standard. ICAO Doc 9303 chip-anchored passport identity is issued by 179 countries as of 2026. Read the chip, verify against the ICAO Public Key Directory, face-match against the on-chip portrait, and you have a strongly-verified personnel identity that no commercial party controls. For remaining countries, document-plus-biometric face-match reaches the same evidential level. Bind that identity to an Advanced Electronic Signature under eIDAS Article 26 and every authorising action carries a cryptographic claim about who signed it.

At the personnel layer this is where Dual Key architecture matters: the authorising signature is split between two parties (user credential + server-side HSM) so that no single party — not the user alone, not the platform alone — can produce a valid authorising command. This is the right threat model for personnel authorisation, because the risk is forgery of a human's assent, and splitting the key across two custodians raises the bar dramatically.

The device side has the same architectural shape but a fundamentally different key model. Hardware secure element (TPM 2.0, discrete secure enclave, or defence-grade equivalent) holds the device's private key — non-extractable, cryptographically bound to the specific silicon at manufacturing time. Every device action (telemetry, sensor reading, autonomous decision, actuator command) is signed against that single hardware-held key. The device produces attestations under RFC 9334 that a verifier can check against the manufacturer's trust roots. Dual Key does not apply here: the threat at the device layer is physical extraction of the key, addressed by hardware non-extractability, not by splitting; and a device operating autonomously in the field cannot depend on a second-party signature per attestation. The audit chain runs: human decision → Dual Key personnel signature → command to device → hardware-anchored device attestation → signed telemetry → verifiable audit record. Every link cryptographically bound to the next; every link verifiable independently against a distinct public trust root.

A Southern European maritime-patrol operator I reviewed architecture with last quarter had exactly this problem inverted: strong hardware attestation on the UAV surveillance platforms, but personnel authorising commands were being logged only against session tokens tied to operator badges. When their audit team asked how a specific reconnaissance mission's authorising officer could be independently identified in a post-incident review, the answer was "trust the login system." That answer works until an incident review actually happens.

Where I disagree with the loud engineering position on this: the argument that "just secure the API" or "just log everything centrally" solves autonomous-system identity is architecturally backwards. Centralised logging without hardware-anchored device identity gives you a story about what happened; hardware-anchored identity with attestations gives you evidence about what happened. In a defence audit or an incident review, the difference between story and evidence is the whole point of the exercise.

What should defence procurement check for in an Identity of Things architecture?

Six questions to put to any autonomous-defence platform quote or architecture-review document before signing off. The vendor's or integrator's answers will usually tell you more about the actual security posture than the marketing document does.

Is the device identity anchored in hardware? Specifically: is the private key inside a non-extractable hardware secure element, cryptographically bound to that silicon? Software certificates in a filesystem do not meet this bar.
Does every meaningful device action produce a signed attestation under RFC 9334 or equivalent? Telemetry, autonomous decisions, actuator commands — each should carry a signature verifiable without the device's cooperation years later.
How is the device identity connected to a human authorising identity? Chip-anchored personnel identity + AdES signature (Dual Key architecture) on the authorising command, bound into the device's action record. Session tokens or API keys break the audit walk-back at the personnel link.
What happens when a device is compromised? Revocation via published trust list, immediate propagation, cryptographic evidence that pre-compromise attestations remain valid. The signature-challenge walk-back pattern in What Happens if Someone Denies They Signed Digitally? applies directly to device disputes.
Is the SBOM signed and independently verifiable under CRA Article 14? An unsigned spreadsheet or a vendor-only-key signature without trust-list anchoring is thin evidence.
Does the audit chain survive the vendor's exit? If the integrator stops operating, do deployed devices still produce verifiable attestations against a public trust root, or does the chain collapse? A deployment that cannot survive its vendor's disappearance is not a deployment; it is a hostage.

My take on this: a defence-procurement decision that treats identity of things as a compliance-checkbox almost always shows up on the wrong side of an audit two or three years later. The retrofit cost when regulation, incident, or contract dispute forces it later is an order of magnitude above the upfront cost — and by then the deployed fleet is the constraint.

Where IdentiGate fits

IdentiGate provides the identity-of-things primitive underneath autonomous-system deployments: hardware-anchored device identity, RFC 9334 attestation binding, and cryptographic integration with the chip-anchored personnel identity layer (Dual Key AdES for authorising commands). Our signature platform and evidence layer keep the full audit chain independently verifiable across the retention periods NIS2, CRA, and defence-procurement contracts require.

If your programme is preparing an EDF SME proposal, a CRA-compliance rollout, or a NIS2 Article 21(2)(d) supplier-register update and the identity-of-things layer is the missing piece, get in touch.

Sources

Legal + regulatory frameworks

Machine identity + attestation standards

Personnel identity standards

About the author

Gustav Poola is a co-founder of IdentiGate, a European identity-verification and digital-signature company building on top of chip-anchored identity-proofing (ICAO 9303 passport NFC), Advanced Electronic Signatures (eIDAS Article 26), Advanced Electronic Seals, and hardware-anchored Identity of Things. He works on the architecture side — deployment patterns for cross-border defence, logistics, healthcare, fintech, and cybersecurity teams — and writes about the intersection of cryptographic primitives, standards, and the practical decisions engineering and procurement teams have to make together.

The words we use in digital identity are load-bearing. Use the wrong one and the listener walks confidently down the wrong road — and in identity, security, and compliance, most of our everyday words send people the wrong way. This is the eleven-point vocabulary repair kit for anyone building identity infrastructure: data vs information, trust vs proof, authentication vs identity, permission vs authority, compliance vs evidence, disclosure vs predicate. If our language keeps reaching for words that can't be measured, are we building resilience — or performing security?

You verify the passport chip — remotely, in ninety seconds, with cryptographic evidence signed by the state that issued the document. The engineering answer for a remote-hire identity check without an in-person meeting is chip-anchored NFC read plus biometric face-match against the chip photo, wrapped in an AdES record retained under a Long-Term Validity envelope. This post walks the pattern for full-time employment remote hires (distinct from gig workers and contractor-of-record engagements), the four questions the pattern actually answers, and where the picture is genuinely harder than the identity layer alone.

Multi-party document signing takes one of two shapes — sequential (party A signs, then B, then C, each signature depending on the previous one) or parallel (all parties sign the same document independently, with an aggregator collecting and combining the signatures). Both are supported cleanly by the eIDAS AdES formats (PAdES, XAdES, CAdES) but the cryptographic semantics, the timestamp coordination, and the LTV envelope requirements differ meaningfully between them. This post walks the two patterns, when to use each, and what tends to break when the pattern is chosen wrong for the workflow.