Governance Across Enterprise and Device PKI: Policy, Ownership, Audit at Scale

Governance for machine identity governance works differently when devices enter the frame. Ownership transfers at manufacturing handoff, multi-tenant device fleets, and 15-year audit trails. The governance gaps that open when enterprise CLM meets IoT PKI, and how to close them.

Governance for machine identity was already difficult when the estate was enterprise certificates: distributed issuance, unclear ownership, shadow CAs, inconsistent policy. Adding device PKI to the governance frame introduces three specific extensions that do not fit cleanly into enterprise governance practice. Ownership transfers across a manufacturing handoff that has no analogue in enterprise certificate lifecycle. Audit trails must persist across decades rather than years. The policy surface expands across regulatory frameworks that enterprise PKI teams are not set up to track.

This is the governance architecture that works across both domains. It builds on the general machine identity governance framework — see machine identity governance for the enterprise side — and extends it specifically for the device domain.

The three governance extensions

Extension 1: Ownership across manufacturing handoff

Enterprise certificates have an ownership model that aligns with team structures. The service owns the certificate; the team running the service owns the service; the team membership database identifies who gets paged when the certificate approaches expiry. This works because the service exists inside the same organisational boundary that runs the PKI.

Device certificates break this. The certificate is issued at manufacturing — typically by the product team or by a contract manufacturer under product team direction. It ships inside the device. The device arrives at a customer, or at the operating team's deployment, and now a different organisation is responsible for what the certificate authenticates. The product team still "issued" the certificate; the operating team "uses" it. Neither is the owner in the enterprise sense.

The working model recognises this as an ownership chain with documented transfer events:

• Manufacturing issuance: product team or OEM is the issuing owner. The audit record captures who authorised issuance and under what policy.
• Deployment handoff: operating team becomes the operational owner. The handoff is a governance event that records what was transferred, when, and under what terms.
• End-of-life: a retirement event records the decommissioning and the certificate's final state. For long-lived device identity, this is when the certificate becomes an audit artifact rather than an operational artifact.

For multi-tenant deployments — an MSO running customer-premise equipment, an industrial operator running OEM equipment for customers — the chain extends further. The OEM manufactures and provisions, the MSO deploys and operates, the end customer has ultimate accountability. Each layer owns different governance responsibilities, and the framework must express the chain rather than collapsing it to a single owner field.

Extension 2: Audit retention across decades

Enterprise audit retention is typically 7 years — long enough to cover most regulatory retention requirements for financial records, long enough to cover typical statute-of-limitations windows. PKI audit trails inherit this default.

Device PKI breaks the default. A Matter Device Attestation Certificate valid for 30 years requires audit evidence of its issuance to remain accessible throughout its validity. An IEEE 802.1AR IDevID installed in an industrial sensor in 2026 and operating until 2046 produces a 20-year audit requirement. The certificate's audit evidence must be present, verifiable, and accessible across that window.

This has three practical consequences:

Storage format must outlast the certificate. Audit records stored in a proprietary format tied to a specific vendor are unlikely to be accessible in 20 years. Standard formats (RFC 5652 Cryptographic Message Syntax, signed JSON, append-only logs with Merkle tree integrity like Certificate Transparency) are the conservative choice.

Integrity must be verifiable independently of the original system. If the CA that issued the certificate is decommissioned in year ten, the audit record for that certificate must remain independently verifiable. This typically requires counter-signing by a third party — a Certificate Transparency log, a trusted archival service, or a periodic integrity anchor published in a durable channel.

Retrieval must work after the original team has turned over. Audit retrieval processes that depend on institutional memory fail at the 20-year horizon. Runbooks, documented schemas, and query interfaces that do not depend on specific staff are essential.

Not every device estate needs 20-year audit retention. The requirement scales with the certificate's role and the regulatory framework. But the PKI governance framework must distinguish between "enterprise default retention" and "long-lived device retention" as first-class policies.

Extension 3: Expanded regulatory surface

Enterprise PKI compliance typically tracks a handful of frameworks: SOC 2, PCI DSS for payment-adjacent systems, HIPAA for healthcare-adjacent, sector-specific financial services regulation. The PKI team works with a compliance team that maintains the mapping.

Device PKI expands this surface substantially. The frameworks that touch device certificates in 2026:

EU Cyber Resilience Act (Regulation (EU) 2024/2847): enforceable from late 2027. Manufacturers of products with digital elements must implement "security by design and by default" including identity management. PKI governance must produce evidence of hardware-backed identity, secure enrollment, and lifecycle management for applicable products.

NIS2 Directive (Directive (EU) 2022/2555): in effect across EU member states. Critical and important entities must implement "state of the art" cryptography and manage the certificate estate as part of risk management. Device PKI for operators in scope is a direct compliance concern.

ETSI EN 303 645 (standard): European consumer IoT baseline. Widely referenced by regulators and increasingly by procurement. Requires unique per-device identity and secure credential storage.

US Cyber Trust Mark (FCC framework): voluntary mark but increasingly driving procurement requirements. References NIST IR 8259A and related publications.

IEC 62443 (series): industrial automation and control systems. Specifies certificate and PKI requirements for IACS components.

IEEE 2030.5 (standard): smart energy profile. Utility interconnection for distributed energy resources requires specific certificate profiles.

Matter Certificate Policy (CSA): PAA recognition, PAI issuance constraints, DAC content requirements.

3GPP specifications: for telecom equipment, certificate enrollment and rotation specifications are part of the carrier procurement baseline.

Each framework has different audit requirements, different certificate content specifications, and different escalation paths in the event of non-compliance. The PKI governance framework must either express a unified policy that satisfies all applicable frameworks or must express framework-specific policies with clear scope boundaries. Most organisations running both enterprise and device PKI find framework-specific policies are the only viable approach — no single policy satisfies SC-081v3 (short public TLS lifetimes) and Matter (long DAC lifetimes) simultaneously.

Policy consistency across distributed issuance

A unified PKI across enterprise and IoT does not imply centralised issuance. The unified PKI pillar outlines three architectures, two of which involve multiple CAs. Governance across distributed issuance is the harder case.

Consistent policy language: the same policy expressed the same way across all issuers. If enterprise CA and device CA use different profile definitions for similar roles, policy drift is inevitable. The governance framework maintains a single authoritative policy repository that all issuers consume.

Consistent enforcement: the issuer enforces the policy it consumes. Governance verifies this continuously — audit the issued certificates against the policy that was supposed to govern their issuance, and alert on deviations. Policy that is published but not enforced is noise.

Consistent inventory: all issued certificates appear in a single inventory, regardless of issuer. Certificate discovery extends across enterprise and device estates. The machine identity certificate sprawl and visibility problem extends to devices: the 15–25% orphan rate observed in enterprise estates becomes significantly worse in device estates where manufacturing-issued certificates may not appear in operational inventories at all.

Consistent audit trail: issuance events across all CAs flow to a single audit system. Per-CA audit trails that cannot be correlated mean that an incident affecting multiple CAs has to be reconstructed manually. Correlation requires consistent identifiers — a certificate's canonical identifier must be resolvable across all audit systems.

Achieving these four across enterprise and device PKI is the practical work of governance. Policy documents are the easy part.

Ownership models for multi-tenant device estates

Telecommunications operators, managed service providers, and industrial service organisations deploy devices they do not own into networks they do not fully control. The governance model must express this.

Operator-owned, operator-deployed: telecoms running their own equipment on their own network. Standard ownership chain; the operator is the sole accountable party.

Operator-owned, customer-operated: managed service equipment on customer premises. The operator owns the device identity; the customer operates the device. Governance questions: who responds to certificate expiry alerts, who authorises device decommissioning, who is named in incident disclosures.

Customer-owned, operator-managed: customer-owned equipment managed by a service provider. The operator does not own the device identity but operates the PKI that issues operational certificates. Requires explicit delegation from customer to operator.

OEM-provisioned, operator-deployed, customer-used: the three-party chain that describes most industrial IoT. OEM installs factory identity, operator adds operational identity, customer consumes the service. Each party has governance responsibilities for different certificate classes.

For Matter specifically, the CSA has formalised the ownership model in the Matter PKI Certificate Policy: PAAs are recognised by the CSA, PAIs are accountable to their PAA, DACs are bound to products, NOCs are bound to fabrics. The model documents who is responsible for what at each layer.

For non-Matter device estates, the ownership model is typically less formalised. The governance framework must document it explicitly rather than leaving it to be inferred from operational convention.

RACI for unified PKI governance

The question "who does what?" in governance is answered by RACI (Responsible, Accountable, Consulted, Informed) mapping. For unified PKI across enterprise and IoT, the RACI expands beyond typical enterprise PKI.

Roles that must be present:

• PKI engineering: operates the CAs, implements policy, maintains the platform. Responsible for issuance mechanics.
• PKI governance: owns policy, audit, compliance mapping. Accountable for the governance framework.
• Product / device engineering: owns factory provisioning integration, device-side enrollment. Consulted on device-specific policy; responsible for device certificate integration.
• Operations: runs the operational estate including device deployments. Informed on policy changes; responsible for operational enrollment.
• Security / incident response: owns compromise response, CA compromise scenarios, fleet-wide rotation events. Accountable for incident response plans.
• Compliance: maps PKI evidence to regulatory requirements. Accountable for audit readiness.
• Legal / procurement: reviews CA provider contracts, manufacturing partner agreements for certificate-related clauses.

The handoff points that the RACI must explicitly cover:

• Policy change approval: who can approve a new profile or a change to an existing one? Typically PKI governance accountable, PKI engineering and product engineering consulted.
• Manufacturing partner changes: who authorises a new contract manufacturer being granted provisioning capability? Typically legal/procurement accountable, PKI governance and security consulted.
• CA rotation events: who decides and executes CA rotation? Typically PKI engineering responsible, security and PKI governance accountable.
• Incident response escalation: who is paged when a device CA is suspected compromised? Typically security responsible, PKI engineering and product engineering consulted immediately.
• End-of-life events: who authorises decommissioning of a device fleet and the associated certificates? Typically product engineering accountable with security and compliance consulted.

Unified PKI RACI failures typically happen at the enterprise-device boundary. Product engineering is not represented in enterprise PKI governance meetings. PKI engineering is not included in product engineering roadmap reviews. Compliance does not track device-side frameworks. The RACI must force these connections; without explicit mapping, the governance gap at the boundary is guaranteed.

Regulatory compliance mapping

Compliance teams need a mapping from regulatory requirement to PKI control. The mapping is specific and has to be maintained as regulations evolve.

A representative mapping for a mid-sized connected product company:

Maintaining the mapping is the compliance team's responsibility. Providing the evidence is the PKI team's responsibility. The governance framework makes the separation explicit so that compliance has a known path to evidence without doing PKI operations work.

What this means for platform selection

Governance-specific evaluation questions for unified PKI platforms:

1. Can the platform produce audit evidence in standard, long-retention formats?
2. Does the platform support ownership chains — multi-party ownership with documented transfer events — rather than single-owner fields?
3. Can compliance queries run across enterprise and device issuance, or does each domain have separate compliance reporting?
4. Does the platform integrate with an immutable audit store (external append-only log, SIEM, Certificate Transparency-style log)?
5. Can policy be expressed at the framework level — "all Matter DACs use CSA-approved chain," "all smart grid endpoints comply with IEEE 2030.5" — and enforced automatically?
6. What is the platform's own audit evidence for its issuance — who operated the platform, what changes were made, when?

Platforms optimised for enterprise governance typically lack the long-retention and multi-party ownership model. Platforms optimised for device provisioning typically lack the enterprise governance integration. The unified platform bridges both, or governance becomes the manual reconciliation work that makes the "unified" PKI only unified at the technical layer.

Further reading

• Unified PKI for enterprise and IoT
• Machine identity governance
• Machine identity certificate sprawl and visibility
• Certificate lifetime policy across enterprise and IoT
• Revocation at device scale
• Device identity for CTOs: strategy, TCO, regulatory compliance