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.

You detect deepfakes at the point where the driver's identity is bound to the freight platform for the first time — at chip-anchored NFC read of the passport plus biometric face-match against the chip's signed photograph, with presentation-attack detection at the device layer. The four deepfake attack vectors that apply to customer onboarding all apply to driver onboarding, but the freight-platform context adds two operational realities that make the stakes higher: driver identity survives across hundreds of shipments per year, and a fraudulent driver identity onboarded once produces cargo-loss exposure downstream. This post walks the specific deepfake-detection architecture for freight driver onboarding, where the traditional flow breaks, and what the fictitious-carrier fraud pattern looks like when it exploits weak driver identity.

You move the identity-proofing operation from a supervised video call to a chip-anchored NFC read plus biometric face-match — ninety seconds, unattended, and the evidence artefact is cryptographically stronger than the supervised alternative rather than weaker. The speed / evidence-quality trade-off that dominated KYC design for the last decade is not a real trade-off in 2026; it is a legacy artefact of an architecture that assumed identity proofing required a human reviewer in the loop. This post walks the four operations inside a KYC verification, where the time actually sits, and how the chip-anchored architecture collapses time without sacrificing evidence quality.

Vendors that combine chip-anchored passport-NFC verification with liveness-plus-injection-attack detection, wrapped in an AdES evidence record. Deepfake-resistance in customer onboarding is not a single feature — it is the intersection of four defence layers, each of which blocks a different attack vector (document forgery, real-time face-swap, presentation injection, synthetic identity). This post walks the four attack vectors, the four defence layers, and the rubric for evaluating any onboarding vendor's actual deepfake posture in 2026.