PLATFORM MODULEREFERENCE ARCHITECTURE

Device Trust & Attestation

Select assurance from L0 passive carrier through L3 runtime attestation according to risk and device capability.

P05Architecture
REFERENCE ARCHITECTUREMaturity
Domain-qualifiedAuthority
SCOPE

What the module does—and what it deliberately does not do.

A clear negative boundary is part of the product definition.

DOES
  • Device binding, certificate lifecycle, hardware-bound keys, secure boot, attestation, appraisal and enforcement.
  • Publishes explicit domain objects and version-aware interfaces/events.
  • Links business outcomes to evidence and architecture references.
DOES NOT
  • Does not replace external legal/identifier authorities.
  • Does not imply universal certification or conformity.
  • Does not make optional assurance mechanisms mandatory for all products.
OPERATING MODEL

Actors, inputs, outputs and authority remain explicit.

The module is not treated as a black box; its authority and evidence responsibilities are visible.

Actors

Device operator · Connected Thing · Attester / Verifier · Policy Decision Point

Inputs

Identity/context, versioned business data, policy inputs and external-source references as applicable.

Outputs

Versioned decision/data/evidence artifacts with correlation and provenance.

Authority boundary

Qualified by data domain; external authority is not absorbed through integration.

BUSINESS OBJECTS

Semantic objects connect UI, API, repository and evidence.

The semantic registry prevents architecture vocabulary from drifting between portals and integration contracts.

Device Trust & Attestation object mapping
IDObjectAuthorityRepository roleAPIArchitecture
OBJ-001ThingDomain-qualifiedThing MasterResolver APIP01/P03
OBJ-007TTIDTrusted ThingID platformResolver registryResolver APIP03
OBJ-021DeviceDevice owner/operator contextDevice RegistryDevice APIP05
OBJ-022Device CertificateDevice PKIDevice Certificate RegistryDevice APIP05
OBJ-023AttestationAttesterEvidence StoreAttestation APIP05
OBJ-024Trust AppraisalPDP/policy authorityDecision logTrust APIP05
POLICY & EVIDENCE

Material actions are policy-versioned and evidence-linked.

Where the module changes a material state, the transition grammar applies.

Event
+
Authorized actor
+
Precondition
+
Evidence
+
Trusted time
+
Policy / profile version
=
Resulting state
INTERFACES & EVENTS

Reference contracts are versioned and publication-gated.

The public API package is a reference contract; actual deployment availability must be confirmed by release/environment.

POST /v1/devices
POST /v1/devices/{id}/attest
GET /v1/devices/{id}/trust
RELEASE GATE
SELECTINTEGRATETESTAPPROVEOPERATE

Publish support only for the exact version/profile/environment that has supporting evidence.

STANDARDS & LIMITATIONS

Mapping is not certification.

Standards are shown with status and implementation wording so reference mapping is not mistaken for assessed conformity.

Relevant standards
ReferenceStatusOJEUImpactImplementation
ISO/IEC 30141:2024INTERNATIONAL STANDARDN/ADevice / integration architectureSUPPORTING
IEEE 802.1ARSTANDARDN/ADevice identity / certificatesSUPPORTING
RFC 8995RFCN/ADevice trustSUPPORTING
ETSI EN 303 645EUROPEAN STANDARDN/ADevice securitySUPPORTING
EU CRAIN FORCE / TRANSITIONN/ADevice/security governanceTRACKED
PRODUCT COMPLETENESS

From module to business outcome.

Extend trust from passive carriers to hardware-backed identity and runtime appraisal with a risk/capability-selected L0–L3 assurance model.

INPUTIdentifier / policy / evidence / source status
OUTPUTSource-aware, policy-qualified result with evidence context
AUTHORITYQualified by data domain; external authority remains external
API / EVENTDevice attestation API
EVIDENCECertificate status · attestation evidence · appraisal decision
MATURITYReference architecture
ARCHITECTURE WORKSHOP

Turn the architecture into a scoped pilot.

Align product-group applicability, authority boundaries, portal journeys, integration contracts and evidence before committing to production claims.