Skip to content
rcrootcerts.com

Change

Standards Radar

Every tracked development carries a visible status, a primary source, and separate proposal, publication and effective dates. A proposal never looks like a requirement.

  • EffectiveTLS · CA/Browser Forum · Standards body

    Public TLS certificate validity capped at 200 days

    Public TLS certificates issued on or after 15 March 2026 may not exceed 200 days. Two further reductions are already scheduled.

    Maximum subscriber certificate validity is reduced in phases: 398 → 200 days (2026-03-15), → 100 days (2027-03-15), → 47 days (2029-03-15). Domain and IP validation reuse periods shrink alongside each phase.

    PKI implication: Issuance profiles, validation reuse, and renewal windows must all be re-tuned.

    Action: Move every public TLS population to ACME or an orchestrated CLM workflow.

    Proposed
    2024-10-09
    Published
    2025-04-11
    Effective
    2026-03-15
    Affects
    Public TLS
    Last verified
    2026-08-01

    Source: CA/Browser Forum — Ballot SC-081v3 (certificate lifetime reduction) · Reviewer: RootCerts editorial — PKI standards desk

  • Published standardACME · IETF · Standards body

    ACME Renewal Information (ARI) published as RFC 9773

    ACME servers can now tell clients when to renew, so renewals can be rescheduled by the CA during mass-revocation events.

    Defines a renewalInfo resource returning a suggested renewal window plus optional explanationURL, letting clients poll and adapt renewal timing instead of relying only on a fixed fraction of lifetime.

    PKI implication: Renewal timing becomes CA-directed rather than client-guessed.

    Action: Enable ARI on ACME endpoints and monitor suggested windows.

    Proposed
    —
    Published
    2025-06-01
    Effective
    2025-06-01
    Affects
    Public TLS, Private TLS
    Last verified
    2026-07-22

    Source: RFC 9773 — Automated Certificate Management Environment (ACME) Renewal Information · Reviewer: RootCerts editorial — automation desk

  • Published standardPQC · NIST · Government

    NIST finalizes ML-KEM, ML-DSA and SLH-DSA

    The first principal post-quantum standards are final. NIST advises organizations to inventory quantum-vulnerable cryptography and plan migration now.

    FIPS 203 (ML-KEM) covers key establishment, FIPS 204 (ML-DSA) lattice signatures, FIPS 205 (SLH-DSA) stateless hash-based signatures. Certificate profiles and hybrid constructions are still stabilizing in the IETF.

    PKI implication: Certificate profiles, HSMs, and CA software all need PQC capability.

    Action: Test ML-DSA issuance in a private hierarchy.

    Proposed
    —
    Published
    2024-08-13
    Effective
    2024-08-13
    Affects
    All certificate types, Key exchange
    Last verified
    2026-07-30

    Source: FIPS 203 / 204 / 205 · Reviewer: RootCerts editorial — cryptography desk

  • Published standardCertificate Transparency · IETF · Standards body

    Certificate Transparency v2 (RFC 9162) Merkle tree auditing

    CT logs use binary Merkle trees so any client can verify that a certificate was logged without downloading the log.

    Defines Merkle Tree Hash, inclusion proofs and consistency proofs over an append-only log, with signed tree heads binding log state at a point in time.

    PKI implication: SCT delivery is a hard requirement for browser acceptance.

    Action: Verify SCT embedding across all issuance paths.

    Proposed
    —
    Published
    2021-12-01
    Effective
    2021-12-01
    Affects
    Public TLS
    Last verified
    2026-07-12

    Source: RFC 9162 — Certificate Transparency Version 2.0 · Reviewer: RootCerts editorial — Web PKI desk

  • Emerging / experimentalPQC · IETF · Standards body

    Merkle Tree Certificates explored in IETF PLANTS

    An emerging construction that integrates certificate issuance with a public log to cut the overhead of large PQC signatures and very short lifetimes.

    Certificate information is represented inside a logged tree; a signed tree head authenticates a batch of entries and individual credentials present compact inclusion proofs instead of full signature chains.

    PKI implication: Would change issuance and distribution assumptions if adopted.

    Action: Follow PLANTS drafts and CA implementation signals.

    Proposed
    2025-02-01
    Published
    —
    Effective
    —
    Affects
    Public TLS (future)
    Last verified
    2026-07-28

    Source: IETF PLANTS working group — Merkle Tree Certificates draft · Reviewer: RootCerts editorial — cryptography desk