Skip to content

Trusted device identities for CRA-ready devices

Cryptographic device identity is a key enabler for the EU Cyber Resilience Act's Annex I essential requirements and its secure-by-design principles. LAAVAT is the platform on which you operate your own PKI to issue two identities per device: a birth certificate (IDevID) provisioned at manufacturing, and an operational certificate (LDevID) issued after deployment. The same platform issues enterprise TLS and OPC UA application certificates from the same pattern.

Why device identity matters

The CRA requires products with digital elements sold in the EU to incorporate security by design across the product lifecycle. Cryptographic device identity is one of the enablers those obligations rest on: it is what lets a product be individually authenticated, which underpins both the "protection against unauthorized access" property in Annex I Part I and the auditability expected of vulnerability handling in Part II.

Two certificates cover most of the device lifecycle:

  • Birth certificate (IDevID) — issued once at the factory, immutable, and the root of trust the operator relies on to accept the device into its network. Defined by IEEE 802.1AR.
  • Operational certificate (LDevID) — issued in the field, carrying the operator's identity assignment for the device, used for all day-to-day communication. Also defined by IEEE 802.1AR.

Together, these let a device attest to its manufacturer of origin, its deploying operator, and its authorised capabilities — the foundation of any CRA-aligned security posture.

The ecosystem

A device passes through two lifecycle phases, each with its counterpart system. During manufacturing, a manufacturing station provisions the birth certificate. In the field, device management takes over certificate lifecycle events, beginning with the issuance of an operational certificate on first connection. The manufacturer's and the operator's certificate authorities are separate entities; both can run on the LAAVAT platform, with the same operation and approval model.

graph LR
    subgraph factory["Factory"]
        D1["<b>Device (birth)</b><br/>generates its keypair on-chip"]
        MS["<b>Manufacturing station</b><br/>requests an IDevID per device"]
    end
    subgraph ops["Operational network"]
        D2["<b>Deployed device</b><br/>presents IDevID · uses LDevID"]
        DM["<b>Device management</b><br/>enrols an LDevID per device"]
    end
    subgraph laavat["LAAVAT platform"]
        MP["<b>Manufacturer PKI</b><br/>issues IDevID · REST"]
        OP["<b>Operator PKI</b><br/>issues LDevID · EST"]
    end
    D1 --- MS
    MS -->|"CSR"| MP
    MP -->|"IDevID"| MS
    D2 --- DM
    DM -->|"CSR"| OP
    OP -->|"LDevID"| DM

In this example, manufacturing calls LAAVAT over REST with a bearer token, and device management calls LAAVAT over EST with HTTP Basic. Enterprise TLS and OT/OPC UA PKIs sit alongside on the same platform.

Auth on each interface is a choice, not a fixed characteristic

This example uses bearer tokens on REST and HTTP Basic on EST for simplicity. Both interfaces also support mTLS as the client authentication mechanism; REST + mTLS and EST + mTLS are equally available on the platform.

Core property — the private key never leaves the device

The device generates its own keypair on-chip. Only the certificate signing request — the public key and identity claims — travels off-device. LAAVAT returns a signed certificate, the public artefact, which the manufacturing station or device management then installs. The private key stays where it was created. The CA keys, likewise, stay in the HSM — see key custody.

IDevID: the manufacturer PKI

The IDevID is the device's immutable, factory-provisioned identity. It is issued once from a PKI under manufacturer control and persists on the device for its operational lifetime. Every device leaving the factory carries one; it is the trust anchor from which the operator later derives its acceptance decision when admitting the device to its network.

Hierarchy

A two-layer hierarchy — a Root CA and an Issuing Sub CA — is the minimum viable configuration. Production deployments may add intermediate CAs.

  • Manufacturer Root CA

    ECDSA P-256 · self-signed

    Created once. Signs the Issuing CA and is otherwise untouched.

    Issues — the IDevID Issuing CA, under two-person approval

  • IDevID Issuing CA

    ECDSA P-256 · Sub CA

    Issues leaves only (pathLenConstraint = 0).

    Issues — one IDevID per device, unattended, at manufacturing volume

  • IDevID

    ECDSA P-256 · leaf

    The device's birth certificate. Subject and SAN from the device's CSR; O and C templated by the profile.

    Held by — the device, for its lifetime

Validity values in the profiles below are examples

Choose values appropriate to your policy. CRL settings are left empty in these example profiles; a production deployment should configure CRL expiry, issue interval and distribution points to support revocation.

Profile: Manufacturer Root CA

Field Value
Profile type Root CA
Key algorithm ECDSA P-256 (secp256r1)
Signature algorithm ECDSA with SHA-256 (self-signed)
Validity 30 years
Subject CN = Manufacturer Root CA; O = Manufacturer
Basic Constraints CA:TRUE, pathLenConstraint = 1 (permits one sub-CA layer below)
Key Usage keyCertSign, cRLSign
Approval Manual (one-time at initial setup)

Profile: IDevID Issuing CA (Sub CA)

Field Value
Profile type Sub CA
Key algorithm ECDSA P-256 (secp256r1)
Signature algorithm ECDSA with SHA-256
Validity 25 years
Subject CN = IDevID Issuing CA; O = Manufacturer
Basic Constraints CA:TRUE, pathLenConstraint = 0 (issues leaves only, no further sub-CAs)
Key Usage keyCertSign, cRLSign
Approval Manual (one-time at setup)

Profile: IDevID leaf

Field Value
Standard IEEE 802.1AR-2018 (baseline in-suite: ECDSA P-256 / SHA-256)
Key algorithm ECDSA P-256 (secp256r1)
Signature algorithm ECDSA with SHA-256 (uniform with the CA chain)
Validity 20 years
Subject template Fixed manufacturer DN (O, C); caller supplies CN and serialNumber via CSR
SAN Caller-supplied via CSR; typically hardwareModuleName otherName (OID 1.3.6.1.5.5.7.8.4) carrying hwType + hwSerialNum. The profile permits SAN types to pass through; it does not itself supply SAN values
Key Usage digitalSignature, keyAgreement
Extended Key Usage id-kp-clientAuth
Basic Constraints CA:FALSE
Uniqueness Unique DN + unique public key — the profile's EnforceUniqueDN and EnforceUniquePublicKey flags
Approval Automated (manufacturing volume)

The profile YAML fields behind these tables are documented in Certificate profiles; example profile files are in Certificate templates.

Creating the PKI in the console

The PKI is built in four stages in the console: design the profiles, create the Root CA, create the Sub CA, and sign the Sub CA and mark it Active. The dialogs are documented in CA hierarchy and Profiles; this section covers what each stage does.

Stage 1: design the profiles

All three profiles — Root CA, Sub CA and End Entity — are created through the same Create Profile dialog. Only the Profile type selector and the field values differ per layer.

Stage 2: create the Manufacturer Root CA

With the profiles in place, instantiate the actual CAs. When the Root CA creation request is approved, LAAVAT:

  • generates the Root CA's keypair inside the HSM — the private key never leaves
  • self-signs the Manufacturer Root CA certificate per the profile
  • publishes the Root CA in the console
  • activates the IssueSubCA operation on this Root, gated by its approval rule

Stage 3: create the IDevID Issuing CA

Same wizard as the Root CA, with one additional early step: picking the parent, which is the Root CA just created.

The Sub CA request goes to the Root's IssueSubCA operation and stays Pending until a member of the Root's approval group approves it. Issuing a Sub CA is the one step in this hierarchy that always needs a second person; leaf issuance later runs unattended.

Stage 4: sign the Sub CA and mark it Active

Once approved, LAAVAT signs the Sub CA certificate with the Root CA and returns it as a PKCS#7 blob. The signed certificate is picked up from the certificate list, converted to PEM and uploaded to the pending Sub CA.

The chain is complete. CA Overview now shows the IDevID Issuing CA nested under the Manufacturer Root CA, both Active. Manufacturing stations can call the Sub CA's IssueCertificate operation with a device-generated CSR; the operation is automated for volume by its blanket-groups rule.

Issuing IDevID certificates

With the hierarchy in place, the manufacturing station issues an IDevID for each device by presenting the device-generated CSR to the Sub CA's IssueCertificate operation. Three things govern this: the structure of the CSR, the mechanics of submission, and the expected structure and validation criteria of the issued certificate.

The CSR

The device generates its own ECDSA P-256 keypair on-chip; the private key never leaves the device. The CSR is a standard PKCS#10 structure carrying:

  • Subject DN — the caller supplies CN and serialNumber. The profile templates O=Manufacturer and C=FI onto the issued certificate regardless of what the CSR contains.
  • Public key — the ECDSA P-256 point the device just generated.
  • Subject Alternative Name — hardwareModuleName otherName (OID 1.3.6.1.5.5.7.8.4, defined in RFC 4108) carrying the device's hardware type OID (hwType) and hardware serial number (hwSerialNum).
  • Self-signature — over all of the above, using the device's private key. This proves the device holds the private key corresponding to the CSR's public key.

A minimal CSR configuration for the IDevID leaf profile:

[req]
distinguished_name = dn
req_extensions     = ext
prompt             = no

[dn]
CN           = device-01
serialNumber = HW-0000000001

[ext]
subjectAltName = otherName:1.3.6.1.5.5.7.8.4;SEQ:hmod

[hmod]
field1 = OID:1.3.6.1.4.1.99999.1.7
# hwSerialNum as hex-encoded OCTET STRING
field2 = FORMAT:HEX,OCTETSTRING:48572d30303030303030303031

Generate the keypair and CSR:

openssl ecparam -name prime256v1 -genkey -noout -out device.key
openssl req -new -nodes -key device.key -config csr.cnf \
    -outform DER -out device.csr.der

# Inspect what the CSR contains:
openssl req -in device.csr.der -inform DER -noout -text

Submission over REST

The manufacturing station authenticates to the LAAVAT API with a bearer token — see API authentication. Issuance is two calls: POST the CSR to the Sub CA's IssueCertificate operation, then GET the resulting request to read the issued certificate. Because the operation's approval rule puts the manufacturing group in blanket groups, with no approval group, the request completes immediately.

POST — submit the CSR

curl -sS -X POST "${API}/cas/${CA}/certificaterequests" \
    -H "Authorization: Bearer ${TOKEN}" \
    -H "Content-Type: application/json" \
    -d "{\"csr\":\"$(base64 -w0 device.csr.der)\",\"operationId\":\"${OP}\"}"

Returns HTTP 202 Accepted — the request is queued, not yet complete. The response body contains the request id (a UUID) and the initial state. Capture the id for the next call.

State values: 1 Created, 2 ApprovalRequired, 4 Approved (about to issue), 8 InProcess, 16 Ready, 32 Rejected, 64 Failed. Terminal states are 16, 32 and 64. For a blanket-group operation like this one, the state usually goes 4 → 8 → 16 within a second or two.

GET — read the issued certificate

curl -sS -X GET "${API}/certificaterequests/${REQ_ID}" \
    -H "Authorization: Bearer ${TOKEN}"

Poll this endpoint — or call it once for automated leaf issuance, which is already Ready by return time. Response fields when state = 16:

  • certificate — the issued leaf, base64-encoded
  • chain — array of base64-encoded certificates from the Issuing Sub CA up to the Root

Decode and save:

jq -r '.certificate' response.json | base64 -d > device.crt
jq -r '.chain[]' response.json | base64 -d > chain.pem

The same flow through signing-tool — production add and production get — is shown in the device certificate example.

Inspect the issued certificate

Two commands cover everything worth reading:

# Full text dump of the leaf
openssl x509 -in device.crt -noout -text

# Verify the leaf against the returned chain
openssl verify -CAfile chain.pem device.crt

The full-text output covers issuer, subject, validity, public key, key usage, extended key usage, basic constraints, and both key identifiers. The one exception is the hardwareModuleName otherName. OpenSSL renders it as othername: 1.3.6.1.5.5.7.8.4::<unsupported> because the otherName inner structure is application-specific. Decode it separately with asn1parse -strparse:

OFF=$(openssl asn1parse -in device.crt \
    | awk '/X509v3 Subject Alternative Name/{getline; print}' \
    | cut -d: -f1 | tr -d ' ')
openssl asn1parse -in device.crt -strparse $OFF

You should see the hwType OID and hwSerialNum OCTET STRING byte-for-byte matching what was in the CSR.

Validation: what makes a correct IDevID

Cross-check the inspected certificate against these properties. All are verifiable from the two openssl commands above; no special tooling required.

Property Expected value
Chain trust Verifies against the Manufacturer Root CA (returned chain has Issuing Sub CA + Root)
Subject: templated fields O=Manufacturer, C=FI (regardless of what the CSR requested)
Subject: pass-through fields CN and serialNumber match the values sent in the CSR
SAN hardwareModuleName otherName present, with hwType and hwSerialNum byte-for-byte matching the CSR
Key algorithm ECDSA on prime256v1 (P-256)
Signature algorithm ecdsa-with-SHA256
Basic Constraints CA:FALSE
Key Usage digitalSignature, keyAgreement — only these two
Extended Key Usage id-kp-clientAuth — only this, never serverAuth on an IDevID
Validity Matches the profile setting. Bounds always: notBefore ≤ now, notAfter ≥ now, ≤ Issuing CA's notAfter
Uniqueness Subject DN and public key are unique across the fleet (enforced by LAAVAT at issuance time)
Key binding The public key in the certificate matches the device's private key (SHA-256 of the DER-encoded public key matches)

LDevID: the operator PKI

Following deployment, the device enrols for an LDevID issued by the operator's PKI. The LDevID conveys the operator-assigned identity for the device, which may differ from the manufacturer-assigned identity carried in the IDevID, and governs all subsequent communication within the operator's network. This is the trust hand-off at the core of IEEE 802.1AR: manufacturer-anchored trust yields to operator-anchored trust.

Operator hierarchy

graph TD
    R["<b>Operator Root CA</b><br/>ECDSA P-256"]
    S["<b>LDevID Issuing CA</b><br/>ECDSA P-256"]
    L["<b>LDevID</b><br/>ECDSA P-256 · leaf"]
    R -->|issues| S
    S -->|issues| L

Only the End-Entity profile is shown; the Operator Root CA and LDevID Issuing CA profiles follow the Manufacturer Root CA and IDevID Issuing CA profiles above, with the operator's subject names.

Profile: LDevID leaf

Field Value
Standard IEEE 802.1AR-2018 (LDevID)
Key algorithm ECDSA P-256
Validity 1 to 2 years
Subject template Operator-defined; may differ from the IDevID
SAN DNS/IP as needed for the operator's network
Key Usage digitalSignature, keyAgreement
Extended Key Usage id-kp-clientAuth, id-kp-serverAuth (per role)
Basic Constraints CA:FALSE
Uniqueness Not enforced
Approval Automated (fleet enrolment volume)

PKI creation follows the same four stages as the manufacturer PKI above: profiles first, then Root CA and Sub CA instantiation in the console.

Issuance over EST

The device — or device management enrolling on its behalf — uses the standard Enrollment over Secure Transport flow (RFC 7030) against the operator's LDevID Issuing Sub CA. One-time platform setup: enable EST on the Sub CA. Per enrolment: fetch the CA chain, submit a CSR, receive the LDevID.

The endpoint shape is https://<est-host>/.well-known/est/<tenant>.<caId>/: the CA is addressed by a URL label following the RFC 7030 <label> convention (§3.2.2). Client authentication uses HTTP Basic over TLS in this example; mTLS is a supported alternative.

1. Enable EST on the Sub CA (one-time)

Before any enrolment can happen, the Sub CA has to be added to the EST service configuration. This is done in the console — Admin → Est Service, pick the CA from the transfer list and send for approval, as described in EST service configuration — or with one REST call:

curl -sS -X POST "${API}/estservice/groups" \
    -H "Authorization: Bearer ${TOKEN}" \
    -H "Content-Type: application/json" \
    -d '{
      "items": [
        { "ca":   "LDevID Issuing CA (EST-enabled)",
          "caID": "<sub-ca-uuid>" }
      ]
    }'

The request is approved in the console. Once approved, the CA's EST endpoint is reachable and accepts enrolments. Only CAs with the Device CA use case are eligible for EST; an approved request replaces the whole EST configuration, so include every CA that should stay published.

2. Fetch the CA chain — cacerts

RFC 7030 §4.1 requires the cacerts endpoint to accept anonymous requests. This lets a device fetch the operator's trust anchor before it has credentials of its own. Two equivalent calls:

# Anonymous (RFC 7030 §4.1)
curl -sS "https://${EST_HOST}/.well-known/est/${LABEL}/cacerts"

# Authenticated — libest example
estclient -g -v -s ${EST_HOST} -p 443 --path-seg ${LABEL} \
    -u ${EST_USER} -h ${EST_PASS} -o work/ --pem-output

3. Generate keypair and CSR

Same pattern as the IDevID case: the device generates its own ECDSA P-256 keypair, and the private key never leaves the device. The CSR carries the operator's identity assignment for this device.

openssl ecparam -name prime256v1 -genkey -noout -out device.key
openssl req -new -nodes -key device.key \
    -subj "/C=FI/O=Operator/CN=device-01.op.example.com" \
    -out device.csr.pem

4. Enrol — simpleenroll

estclient -e -v -s ${EST_HOST} -p 443 --path-seg ${LABEL} \
    -u ${EST_USER} -h ${EST_PASS} \
    -y device.csr.pem -o work/ --pem-output

# Result: the issued LDevID lands at work/cert-0-0.pem
openssl x509 -in work/cert-0-0.pem -noout -subject -issuer -dates

5. Renew — simplereenroll

When the LDevID nears expiry, the device presents its existing LDevID (client certificate) and private key to prove possession, and requests a fresh certificate from the same Sub CA:

estclient -r -v -s ${EST_HOST} -p 443 --path-seg ${LABEL} \
    -c cert-original.pem -k device.key \
    -u ${EST_USER} -h ${EST_PASS} \
    -o work/ --pem-output

The EST client is illustrative

The examples above use Cisco's libest (estclient) as the EST client; any RFC 7030-compliant client works — openssl-scripted flows, curl-based clients, vendor tooling, or an embedded EST client in the device's own stack. The endpoints, request bodies and response formats are the standard-defined ones.

Once the LDevID is installed, the device holds two certificates: the manufacturer-issued IDevID, proof of identity to any operator that trusts the manufacturer root, and the operator-issued LDevID, used for all operational communication within the operator's network.

Other supported use cases

Beyond device identity, the same platform issues certificates for enterprise TLS and for OPC UA applications on the plant floor. They are included because a deployment rarely stops at device identity, and the hierarchy pattern and the operation model are the same as for IDevID and LDevID; only the profile differs. As above, only the End-Entity profiles are shown.

Enterprise TLS

Certificates for internal services and users. The hierarchy follows the same Root CA + Issuing Sub CA structure; the distinguishing element is at the leaf layer, where the server and client profiles differ.

Profile: TLS server leaf

Field Value
Key algorithm ECDSA P-256
Validity 90 days to 1 year
Subject CN = primary DNS name
SAN Required. DNS/IP entries (RFC 6125)
Key Usage digitalSignature, keyEncipherment or keyAgreement
Extended Key Usage id-kp-serverAuth

Profile: TLS client leaf

Field Value
Key algorithm ECDSA P-256
Validity 1 year
Subject CN = user or service principal name
SAN rfc822Name or URI
Key Usage digitalSignature
Extended Key Usage id-kp-clientAuth

OPC UA in OT networks

OPC UA is the dominant open protocol on plant floors for machine-to-machine communication. Its security model requires each application — server or client — to hold a certificate, and the protocol's certificate validator is prescriptive about the certificate's contents. Certificates that fail its checks are rejected at connect time with specific BadCertificate* error codes; this makes OPC UA the one use case where correctness is enforced by the protocol itself rather than by trust policy.

Three characteristics distinguish an OPC UA application certificate from a generic TLS certificate:

  • Application URI in SAN (required). The Subject Alternative Name must include a URI entry (for example urn:manufacturer:LineController-01) that matches the ApplicationUri declared in the application's ApplicationDescription. If the URI is missing or does not match, the client rejects with BadCertificateUriInvalid.
  • Both server and client EKU. Applications typically act as both server and client in OPC UA, so the Extended Key Usage carries both id-kp-serverAuth and id-kp-clientAuth.
  • Full Key Usage bit set. The Key Usage extension must include digitalSignature, contentCommitment, keyEncipherment and dataEncipherment. This is broader than a typical TLS certificate.
graph TD
    R["<b>OT Root CA</b><br/>ECDSA P-256"]
    S["<b>OPC UA Issuing CA</b><br/>ECDSA P-256"]
    L["<b>OPC UA application certificate</b><br/>ECDSA P-256 · leaf"]
    R -->|issues| S
    S -->|issues| L

Profile: OPC UA application leaf

Field Value
Standard OPC UA Part 6 (Mappings)
Key algorithm ECDSA P-256
Validity 1 to 5 years
Subject CN = application name
SAN Application URI (required) plus DNS/IP entries
Key Usage digitalSignature, contentCommitment, keyEncipherment, dataEncipherment
Extended Key Usage id-kp-serverAuth and id-kp-clientAuth
Basic Constraints CA:FALSE

For both use cases, PKI creation and issuance follow the same profile-driven, operation-based pattern as the device identity example above.

References