Certificate Lifetime Policy for Enterprise and IoT: 47 Days Meets 10 Years

Enterprise TLS is heading to 47-day validity under SC-081v3. Matter DACs live decades. Industrial sensors outlast their CAs. The policy framework for managing certificate lifetimes across an estate where the range spans three orders of magnitude.

Certificate lifetime is the single axis where enterprise and IoT PKI diverge most visibly. The enterprise trajectory is driven by the CA/Browser Forum and the web PKI ecosystem: shorter, automated, rotated aggressively. The IoT reality is driven by physics and economics: devices in sealed enclosures, devices without reliable connectivity, devices whose manufacturer ceased to exist before the certificate expires.

A unified PKI has to hold both positions simultaneously. Policy cannot be "certificates live 47 days" or "certificates live 10 years" — it must be "certificates live 47 days for this class of endpoint and 10 years for that class, and both are correct." Getting this right requires a lifetime framework that maps device class and deployment context to validity policy rather than applying a single number across the estate.

The enterprise trajectory: SC-081v3 and beyond

CA/Browser Forum ballot SC-081v3, passed in April 2025 and effective in March 2026, established the phased reduction of publicly trusted TLS certificate validity:

• March 15, 2026: 200 days maximum (already in effect as of this writing)
• March 15, 2027: 100 days maximum
• March 15, 2029: 47 days maximum

The 47-day endpoint is a deliberate choice. It is short enough that manual certificate management is infeasible — forcing automation — but long enough that a weekly renewal cadence leaves operational slack for failure recovery. The trajectory matches the direction already set by Let's Encrypt's 90-day default, which proved that aggressive rotation is survivable when the rotation is automated.

Private PKI is not bound by SC-081v3. An organisation running internal PKI for non-browser-trusted certificates can issue 398-day or longer internal TLS certificates indefinitely. In practice, most mature enterprise PKI has already moved to 90-day or shorter internal lifetimes, driven by the operational observation that the gap between automated and manual certificate management narrows as lifetimes shrink.

The implication for unified PKI: the enterprise side of the estate is converging on a narrow lifetime band — 47 to 90 days for TLS, weeks for short-lived workload identity, hours for ephemeral CI/CD — with full automation as a precondition. Certificate lifetime at the enterprise layer is no longer a policy debate; it is an operational automation requirement.

The IoT reality: decades, physics, and IEEE 802.1AR

Matter Device Attestation Certificates are specified by the CSA Matter Certificate Policy to last the operational lifetime of the device. In practice this means validity measured in decades. The reasoning is concrete:

• A Matter-certified smart bulb sold in 2026 may be in service in 2040.
• The bulb has no firmware update mechanism for rotating the DAC.
• The DAC proves the device was manufactured by an authorised party, which is a property that should not expire.

The same logic applies to other long-lived device identities. Industrial sensors on a factory floor, medical devices in hospitals, automotive components — the certificate has to outlast the organisational appetite for replacing the device.

IEEE 802.1AR formalises the two-tier model that lets this work alongside operational security:

• IDevID (Initial Device Identity): installed at manufacture in secure hardware, immutable, designed to last the device lifetime. The IDevID proves "this device is what the manufacturer says it is." Validity typically 10–30 years.
• LDevID (Locally Significant Device Identity): issued by the operator after deployment, scoped to a specific network or fabric, rotatable. The LDevID proves "this device is authorised to operate in this network right now." Validity typically 90 days to 2 years.

The two-tier model decouples "who the device is" from "what the device is currently allowed to do." A device can hold a 20-year IDevID and rotate its LDevID every 90 days. The long-lived identity never transits the operational network; the operational identity can be rotated without factory access.

Matter applies a similar split: the DAC is long-lived and manufacturer-issued, the Node Operational Certificate (NOC) is fabric-issued and scoped to the specific Matter fabric the device joins. Lifetime policy for a Matter device is therefore two policies — DAC and NOC — with different durations.

ETSI EN 303 645, the European consumer IoT baseline security standard, accommodates this explicitly: it requires cryptographic identity per device without mandating short rotation, recognising that consumer IoT field conditions do not support enterprise-style rotation cadence.

The policy framework: profiles, not numbers

Unified PKI lifetime policy is expressed as a set of profiles, each with its own validity, algorithm, and extension policy. The number of profiles required is smaller than teams expect — six to ten profiles typically cover a mixed enterprise-IoT estate. The discipline is to keep the profile set small, documented, and consistent.

A representative profile set for a mixed estate:

The profile, not the protocol, holds the validity. A CSR arriving via ACME, EST, SCEP, or CMPv2 maps to a profile based on requester authorisation and requested profile identifier; the CA applies the profile's validity and algorithm policy consistently. See PKI enrollment protocols for enterprise and IoT for the protocol layer.

The CA hierarchy must support the longest profile. If your longest leaf profile is a 30-year Matter DAC, the issuing CA must have validity exceeding 30 years, and the root must exceed that. A CA hierarchy designed for 5-year enterprise certificates cannot host device profiles without re-rooting. This is a common constraint that forces organisations adding Matter or long-lived device identity onto an existing enterprise PKI to build a new hierarchy.

Coherent rotation across mixed lifetimes

Rotation policy in a unified PKI is not one policy. It is a set of policies keyed to profile, and the operational systems that respond to rotation must understand the profile.

Enterprise TLS rotation (47–100 days): fully automated via ACME with RFC 9773 ARI guiding renewal windows. The operational system is the CLM plus ACME client infrastructure. Failure mode: automation regression. Mitigation: monitoring and alerting at the CLM layer.

Workload identity rotation (minutes to hours): automated through the service mesh or SPIFFE infrastructure. No human in the loop. Failure mode: issuance service unavailability. Mitigation: CA high availability and short-lived credentials with graceful degradation.

LDevID rotation (90 days to 2 years): device-side enrollment via EST. Requires the device to be online and to have capacity to re-enroll. Failure mode: device offline during renewal window. Mitigation: sufficiently long renewal window and re-enrollment on reconnection.

IDevID / DAC rotation (10+ years): not rotated in normal operation. The rotation event is catastrophic — CA compromise, algorithm deprecation, fundamental policy change. Requires physical or OTA firmware replacement. Failure mode: fleet-wide inability to accept the rotation. Mitigation: design the device from day one to accept a new IDevID via signed firmware update, and never assume this will work until you have tested it.

The dangerous case is treating any of these four models as another model. Enterprise automation applied to IDevIDs produces devices trying to rotate 20-year certificates via ACME. IDevID thinking applied to enterprise TLS produces certificates that sit unrotated until they expire during a platform migration in year eight. The unified PKI must expose all four rotation models as first-class, not as variants of one.

Cryptographic algorithm policy alongside lifetime

Lifetime policy is incomplete without algorithm policy, because a 20-year certificate issued today must remain secure until the 2040s. The algorithm choices for different lifetime tiers differ accordingly.

Short-lived enterprise TLS (47–100 days): ECDSA P-256 or Ed25519 is current standard. The lifetime is short enough that algorithm agility — the ability to rotate to a different algorithm within the lifetime window — is the primary defense. Post-quantum transition will happen via rotation, not re-issuance of existing certificates.

Long-lived device identity (10+ years): the algorithm choice must survive the validity period. ECDSA P-256 is currently acceptable; ECDSA P-384 provides additional margin. RSA-2048 is increasingly marginal for 10-year-plus lifetimes. Post-quantum algorithms — ML-DSA (FIPS 204) and the Stateful Hash-Based Signatures in SP 800-208 — are the candidates for new long-lived identity. NIST IR 8547 provides the transition guidance.

Matter DACs: the CSA Matter specification mandates ECDSA P-256. This is locked by the ecosystem; an organisation issuing Matter DACs does not have algorithm discretion here. Post-quantum Matter is a future ecosystem decision.

The policy framework therefore has to tie algorithm choice to lifetime tier, and the crypto-agility discussion becomes: for short-lived tiers, agility is the plan; for long-lived tiers, conservative algorithm choice plus designed-in device capability to accept a new identity is the plan.

Audit and compliance implications

Auditors increasingly ask questions that only a coherent lifetime policy can answer:

• What is the longest-lived certificate currently issued under your PKI?
• What is the algorithm of that certificate, and what is your post-quantum migration plan for it?
• What proportion of your certificate estate is rotated through automation vs manual process?
• For certificates with lifetime exceeding 5 years, what is the identity, owner, and rotation plan for each?

A PKI that cannot answer these questions is exposed in compliance audits under frameworks like NIS2, the EU Cyber Resilience Act, and US sector-specific regulation. Axelspire's assessment of client PKI estates typically finds 3–7% of certificates with lifetimes exceeding 3 years, unattributed to owners, with no rotation plan. These are the pages of the certificate inventory that auditors circle.

For the governance side of this — ownership, policy enforcement, audit trail across mixed profiles — see governance across enterprise and device PKI. For the revocation side of long-lived credentials — since CRL and OCSP do not scale to device revocation — see revocation at device scale.

What this means for platform selection

The lifetime-specific evaluation questions for a unified PKI platform:

1. Does the CA support per-profile validity policy, or does it apply a single validity rule across the CA?
2. Does the issuing CA hierarchy support validity periods long enough for your longest leaf profile — including Matter DAC, IDevID, and long-lived industrial identity?
3. Does the rotation model differ per profile, or does the platform assume one rotation cadence?
4. Can the platform express algorithm policy as part of the profile, or is algorithm fixed at the CA?
5. Is there an audit query that lists all certificates by lifetime tier, so you can find the long-tail long-lived certificates?
6. Does the platform support the RFC 9773 ARI signal for short-lifetime profiles while leaving long-lifetime profiles outside ARI?

A platform that answers "yes" to all six supports the mixed lifetime estate. A platform that answers "we use one default validity" is suitable for either enterprise or IoT, not both.

Further reading

• Unified PKI for enterprise and IoT
• PKI enrollment protocols for enterprise and IoT
• Revocation at device scale
• Mixed key storage in unified PKI
• Matter PKI
• Matter Device Attestation Certificates