Preparing for 47-day TLS certificates with automated renewal

Why 47-day TLS certificates change how regulated teams run renewal

If your certificates are renewed by hand or tracked in a spreadsheet, the CA/Browser Forum Baseline Requirements will make that approach fail on a fixed schedule. Publicly trusted TLS subscriber certificates are capped at 200 days from March 15, 2026, at 100 days from March 15, 2027 and at 47 days from March 15, 2029. A team that renews a handful of certificates per year can absorb manual work. A team that holds hundreds of public and internal certificates renewing every few weeks cannot, and a single missed renewal produces an outage on a production service. The practical answer is automated issuance and renewal from a known inventory, with the renewal path tested before the shorter lifetimes arrive. Where certificates live determines the tool: step-ca for ACME and API-driven issuance to servers and services, cert-manager for Kubernetes workloads, OpenBao PKI where secrets and keys already sit, and FreeIPA Dogtag for Linux estates that already run FreeIPA.

Internal certificates usually follow the same logic even though no browser policy requires it. Service-to-service mutual TLS, ingress certificates, staff device certificates and internal admin portals were often issued with multi-year lifetimes because nothing forced renewal. Those certificates now carry the same expiry risk, and a short-lived design for them is a decision your own security policy can make. Start by asking your team to confirm three things: which certificates are publicly trusted and which come from a private CA, which owner renews each one, and which systems cannot be restarted or reconfigured without a change window. Those answers decide which issuance path each certificate needs and where ACME automation is possible at all.

Expect the inventory to be the hardest part. Scanners and CA databases rarely agree, so reconcile them before choosing any tool, and record the owner, issuer, lifetime and deployment target for each certificate. Then confirm that each renewal path works end to end in a non-production environment, including the reload of the service that consumes the certificate. Ask any implementation partner to show how the inventory feeds expiry alerts and audit evidence, because regulators and assessors will ask how you know a certificate was renewed, not just that it was issued.

What the lifetime schedule and audit rules require from your build

This table maps the CA/Browser Forum validity schedule and two US audit and transmission rules to concrete build requirements. Read each row as a design consequence: the requirement on the left, what it means for your inventory, renewal, logging and encryption design in the middle, and the evidence to keep on the right.

Requirement	What it means for the build	Evidence to keep
CA/Browser Forum validity cap: 200 days from March 15, 2026	Public certificates issued after this date cannot exceed 200 days, so manual renewal calendars that assume annual certificates no longer hold. Confirm which of your certificates are publicly trusted and which come from a private CA.	Current validity periods per certificate, and a dated list of certificates issued under the 200-day cap.
CA/Browser Forum validity cap: 100 days from March 15, 2027	Renewal frequency roughly doubles against the 2026 cap, so renewal must run without tickets. Confirm with your CA or vendor how renewal is triggered and who receives failure alerts.	Renewal job logs, failure alert records and a tested runbook for a renewal that did not complete.
CA/Browser Forum validity cap: 47 days from March 15, 2029	The final schedule leaves little room for manual steps. Every public and internal endpoint needs an automated renewal path (for example ACME) and a tested reload or rotation method.	Automation coverage report showing each endpoint, its renewal method and its last successful renewal.
Ballot SC-081v3 context	The ballot set the reduction schedule and the data reuse periods that go with it. Read the ballot text to confirm which reuse rules apply to your validation methods, and plan re-validation of domain control on the same cadence.	Record of which domain validation methods your team uses and the reuse period your CA applies to each.
Complete certificate inventory	Both the public schedule and the audit rules assume you know every certificate in use. Build the inventory from CA issuance logs, scanners and Kubernetes secrets, and reconcile the three sources on a fixed schedule.	Dated inventory with owner, issuer, expiry, key location and the service that consumes each certificate.
45 CFR 164.312 unique user identification and audit controls (HIPAA)	Certificate issuance must trace back to an identified requester. Bind each ACME account, provisioner or workload identity to a named owner or service identity, and record issuance, renewal and revocation events. Confirm with your compliance lead which systems hold ePHI and therefore fall in scope.	Issuance and revocation logs tied to unique identities, plus the list of in-scope systems and their owners.
16 CFR 314.4 logging of authorized user activity and encryption in transit (FTC Safeguards)	Short lifetimes multiply certificate events, so log volume grows. Forward CA and renewal logs to your SIEM, and confirm that TLS settings on each service enforce encryption in transit for customer information.	Forwarded CA audit logs, retention settings and TLS configuration results for in-scope services.
Revocation and logged events	Shorter lifetimes reduce how long a compromised certificate is useful, but they do not replace revocation. Confirm how your CA publishes revocation status and how that status reaches clients inside your network.	Revocation procedure, test records for revoking one certificate, and the revocation publication method.

Which certificates the 47-day schedule covers and which you control

Publicly trusted TLS subscriber certificates are the ones browsers and operating systems accept because a public certificate authority issued them under the CA/Browser Forum Baseline Requirements. Those requirements cap validity at 200 days from March 15, 2026, 100 days from March 15, 2027 and 47 days from March 15, 2029. The cap applies to the certificate itself, so no internal decision can extend it for a public hostname.

Scope of the cap: Any certificate that chains to a publicly trusted root for a public hostname falls under the schedule, including customer-facing websites, APIs and partner endpoints.
Who renews: Your team or the hosting provider must renew, so automation through ACME or the provider's API is the only practical path at 47 days.
Load balancers and CDNs: Certificates installed on edge devices often need manual steps, so list them separately from web servers in your inventory.
Vendor-managed endpoints: Confirm with each SaaS or hosting vendor who issues and renews the certificate and how quickly they rotate it.
Renewal timing: Plan renewals well before expiry, because the shorter window leaves less room to recover from a failed renewal.

Confirm with each public certificate authority which ACME features and validation methods it supports for your domains before you commit to a design.

How to build a certificate inventory before you automate

Automation fails silently on certificates it does not know about. A renewal job only renews what it has been pointed at, so a certificate on a forgotten load balancer or an appliance web console will expire on schedule while every dashboard you trust stays green. Build the inventory first, then automate against it. Start from the places certificates are actually installed: load balancers and reverse proxies, Kubernetes ingress controllers and the Secrets that back them, cloud certificate stores, web and application servers on Linux and Windows, network appliances and firewalls, and mail, VPN and directory services. Then run network scanning across internal address ranges to catch what no team has documented.

For each certificate, record the issuer, subject, subject alternative names, expiry date, owner, key location (software store, HSM, cloud KMS or hardware token) and the consuming system that loads it. The owner and consuming system fields are the ones teams skip, and they decide who gets paged when a renewal fails. Store the inventory in a system of record that your auditors can query, and keep discovery running on a schedule so that new certificates appear without a manual step. Confirm discovery coverage in each environment instead of assuming it: check which network segments and cloud accounts the scanners can reach, whether the Kubernetes discovery role can read Secrets across namespaces, and whether appliances that do not expose certificates through a supported interface need manual entries. Document the gaps as known exceptions with a named owner.

The inventory is also the audit evidence. Assessors reviewing key and certificate management usually ask which certificates exist, who issued them, when they expire and how renewal is controlled, and a current, timestamped inventory answers those questions directly. Keep historical snapshots so you can show that expiry monitoring and renewal ran over time. Before you change any renewal tooling, ask your implementation partner to reconcile the discovered list against your CA's issuance records and against the list of certificates your teams already know about, and agree in writing how unmatched entries are resolved.

Which open-source platforms fit each part of the renewal problem

Short-lived certificates only work when issuance, renewal and trust distribution are automated end to end. The platforms below cover different parts of that chain, from a general-purpose CA to Kubernetes workloads and Linux identity estates, and the right mix depends on where your certificates live today.

step-ca for general issuance

step-ca is Smallstep's online certificate authority for X.509 certificates, licensed under Apache-2.0. It supports ACME for automated renewal and authorizes requests through ACME, OIDC, cloud instance identity and JWK provisioners, so each requester proves who it is before a certificate is issued. Check where the CA keys will sit (HSM, cloud KMS or YubiKey) and confirm which provisioner fits each service class before you set lifetimes.

cert-manager for Kubernetes workloads

cert-manager is a Kubernetes controller under Apache-2.0 that requests TLS certificates for workloads, stores them in Kubernetes Secrets and renews them before expiry. It works with ACME, a CA key pair, HashiCorp Vault, CyberArk or self-signed issuers, and it runs on OpenShift as well. Confirm which issuer each namespace uses, how trust bundles reach pods, and how expiry is monitored across clusters.

OpenBao PKI for secrets-centric teams

OpenBao is an MPL-2.0 licensed, OpenSSF-hosted fork that manages secrets, certificates and keys. Its PKI capability fits teams that already keep credentials in a central store and want certificate issuance governed by the same policies and audit trail. Confirm that the PKI engine, roles and renewal workflows meet your certificate profiles, and plan how other services will authenticate to request certificates.

FreeIPA Dogtag for Linux estates

FreeIPA bundles a Dogtag certificate authority with identity management for Linux hosts, users and services. It suits estates where host enrollment, Kerberos and certificate issuance should be managed together. Confirm how certificate requests are approved for hosts and services, how renewals are triggered on machines with no interactive administrator, and whether Dogtag meets your key custody requirements.

Licensing check before choosing HashiCorp Vault

HashiCorp Vault from version 1.15.0 is licensed under the Business Source License 1.1, with IBM named as licensor. That license is not an OSI-approved open source license, so a team that wants open source terms should weigh it before building certificate workflows on Vault. Decide on licensing with legal and procurement first, then compare Vault against OpenBao, which is MPL-2.0 licensed.

Choosing internal lifetimes your renewal pipeline can actually meet

Shorter internal lifetimes shrink the window in which a stolen or misissued certificate is useful, but they also make every certificate depend on your CA and your renewal automation being healthy on a regular schedule. A 47-day public lifetime is set by the CA/Browser Forum for publicly trusted certificates, and the public schedule is a ceiling for those certificates only. Your private lifetimes in step-ca, cert-manager or OpenBao PKI are your own decision, and the right value is the shortest one your pipeline has proven it can renew without incident. Before changing any profile, confirm the renewal window you intend to use, and make sure it leaves several retry opportunities before expiry rather than a single attempt.

Test renewal success rates across every workload class, not only the easy ones. Run a sample of certificates through ACME issuance or the CA issuer for several weeks at the proposed lifetime, and record each failure with its cause: DNS or challenge errors, expired provisioner credentials, network paths to the CA, or rate limits on the issuing side. Then test reload behavior. A renewed certificate only helps if the process serving it picks up the new file without a restart, so check each service for hot reload support, confirm how cert-manager updates mounted Secrets in your pods, and note which applications still need a manual or scripted reload. Those services set the practical floor for your lifetimes.

Test CA availability and failure behavior before the first short-lived certificate reaches production. Decide how long a service can run on its current certificate if issuance is unavailable, who is paged when renewal fails, and whether the CA's high availability design, key storage and backup have been exercised. Run a deliberate outage drill: take the CA or the issuer offline for a defined period and watch which certificates reach their renewal threshold. The result tells you whether your chosen lifetime leaves enough slack. Ask your implementation partner to document this as a runbook with alerts on expiry approaching, not only on expiry itself, and confirm the drill results before lowering any lifetime.

Rollout phases and the output of each

The sequence moves from knowing what certificates exist and who owns them, to automating issuance and renewal on one low-risk service, to migrating each estate and handing the running system to the team that will operate it. Each phase ends with a named artifact that the next phase depends on.

Discover scope and build the certificate inventory
Start by finding every certificate that matters: public TLS endpoints, internal web services, Kubernetes ingress and workload certificates, load balancers, appliances, and client or mutual TLS certificates. Record the issuer, subject names, key type, expiry date, the system it protects and a named owner for each entry. Discovery usually combines the outputs of your CA logs, DNS and cloud inventories, and a network scan, and the team should confirm that every source is covered. The step is done when the inventory has an owner for every line and the owners have accepted responsibility in writing. Output: the certificate inventory with owners.
Design certificate profiles, lifetimes and provisioners
Define the rules the automation will enforce: which CA or issuer signs each class of certificate, the maximum lifetime per profile, the key algorithms and extended key usages allowed, and the subject naming conventions. Decide which provisioners or authentication methods may request certificates, such as ACME for public and internal names, OIDC or cloud instance identity for workloads, and JWK for bootstrap. Confirm with your CA vendor or project documentation which provisioner and issuer types your chosen tools support before committing to a design. The step is done when the profiles and provisioners are written, reviewed by security and the service owners, and approved. Output: certificate profiles, lifetimes and provisioners.
Pilot automation on a low-risk service
Choose one internal service with a clear owner, a non-critical role and a test environment. Configure ACME or the relevant issuer so the certificate is requested, installed, reloaded and renewed without manual steps, then test the failure paths: a renewal that fails, a CA that is unreachable, and a rollback to the previous certificate. Run the renewal through at least one full cycle under the shortened lifetime chosen for the pilot. Write the steps as a runbook that an operator who did not build the pilot can follow. The step is done when the runbook has been executed successfully and the failure tests have recorded results. Output: tested renewal runbook.
Migrate services by estate
Move the remaining services in groups, such as a Kubernetes cluster, a set of virtual machines managed by one configuration tool, or a particular business unit. For each group, replace manually installed certificates with automated issuance, confirm trust is distributed to clients and that services reload their certificates without a restart outage where the platform allows it, and retire the manual process. Track progress against the inventory so that every entry shows whether it is automated, scheduled for migration or an accepted exception with an expiry date for the exception. The step is done when each estate's services are either automated or listed as a documented exception. Output: automated services list.
Set up monitoring and expiry alerting
Automation can fail silently, so build independent checks that compare live certificates against the inventory and the expected renewal dates. Alert on certificates approaching expiry, on renewal failures, on certificates present on endpoints but absent from the inventory, and on CA health problems. Route each alert class to a named owner with an escalation path, and test the routing by triggering a controlled failure. Confirm whether your public certificates also need monitoring for certificate transparency logs, which depends on your domain and issuer choices. The step is done when a test alert reaches the right owner and the escalation has been exercised. Output: alert routing.
Hand over operations with runbooks and an evidence pack
Transfer the running system to the operations team with runbooks for routine renewal checks, CA key and provisioner changes, revocation, incident response for a failed renewal, and adding a new service. Assemble an evidence pack that shows the inventory, profiles and lifetimes, change records, test results, alert routing tests and the exception register, so that internal audit or an external assessor can trace the control. Agree who reviews the inventory on a regular cadence and who approves new exceptions. The step is done when the operations team has run one routine task unassisted and the evidence pack has been reviewed by the control owner. Output: runbooks and evidence pack.

Evidence assessors ask for and which component produces it

This table maps the evidence an assessor is likely to request for short-lived certificate operations to the component that generates it. Read each row as a question to ask your team: where does this record come from, who holds it, and how long is it kept. DeployOpen prepares this evidence, but independent auditors and certification bodies decide whether it meets the applicable requirement.

Evidence	Component that produces it	What to confirm before the assessment
Certificate inventory export	Inventory tool or external scanner that reads certificates from endpoints, load balancers and cluster secrets	Whether the export covers every public and private certificate, with owner, expiry date and issuing CA for each
Issuance logs and provisioner configuration	step-ca logs and provisioner settings, or OpenBao audit devices for its PKI secrets engine	Which provisioners can issue, which identities they trust, and whether logs are shipped off the CA host
Renewal success records	ACME client logs or cert-manager events and certificate status conditions	Failed renewal alerts, how quickly failures reach an owner, and whether records survive pod or cluster rebuilds
Revocation records	The issuing CA's revocation database and published CRL or OCSP responder output	Whether revocation covers compromised keys and decommissioned services, and how relying systems check status
Key custody records	HSM audit logs, cloud KMS key policies and access logs, or YubiKey custody logs for CA keys	Who can use or export CA keys, how key ceremonies were recorded, and where custody documents are stored
Transmission security configuration	TLS policy on load balancers, ingress controllers and service mesh, plus the CA trust bundle distributed to clients	Minimum protocol versions, approved cipher suites, and whether every internal hop that carries sensitive data enforces the policy

What buyers ask before bringing in an implementation partner

How much effort do the certificate inventory and migration take?

The effort depends on how many certificates exist, where they are issued, and how many systems consume them. Most teams underestimate the inventory because certificates sit in load balancers, appliances, Kubernetes secrets, mail servers, vendor-managed endpoints and old scripts that nobody owns. The main drivers are the number of certificate issuers in use, whether renewal is manual or already automated, how many platforms must be reconfigured to fetch certificates automatically, and whether internal services need a private CA or can stay on public issuance. Ask any partner to scope the inventory discovery as a separate phase, with a written list of sources scanned and the systems each certificate touches before migration is priced.

Can our team handle the move to shorter certificates internally?

Many teams can complete part of the work internally, especially where they already run an ACME client or a Kubernetes certificate controller. The harder parts are usually coordination and ownership: agreeing on certificate profiles, mapping each service to a renewal method, and testing reloads without outages. Teams without a dedicated PKI owner often struggle with root and issuing CA key handling, trust distribution to clients and devices, and monitoring for failed renewals. A practical test is whether your staff can name the owner of every certificate in the inventory and can rehearse a renewal failure. If not, a fixed-scope engagement can cover the gaps while your staff keep operational control.

What does the work require from our internal staff?

Your staff must supply knowledge that no outside team can infer from the network diagram. Expect to provide named owners for applications and appliances, change windows for each system, access to DNS and load balancer configuration, and decisions on which services need public trust and which can use a private CA. Security and platform engineers also need to approve certificate profiles, key storage, and the process for revoking a compromised certificate. Plan for reviewers from application teams, because they must confirm that their software reloads new certificates without a restart. Ask the implementation partner to publish a responsibility matrix before work starts so each dependency has a named person.

How do the 2026 and 2027 validity steps change the plan?

The CA/Browser Forum Baseline Requirements cap publicly trusted TLS subscriber certificate validity at 200 days from March 15, 2026, at 100 days from March 15, 2027, and at 47 days from March 15, 2029. Each step halves the time available to renew, so manual renewal that works at one year becomes a recurring task measured in weeks. The plan should therefore move from calendar reminders to automated renewal well before the first cap takes effect. Confirm with your public certificate vendor which ACME or API options they support, and check whether your own private CA profiles will follow the same lifetimes. Note that these caps apply to publicly trusted certificates, so internal services may set their own lifetimes.

What does running short-lived certificates cost to operate over time?

Short-lived certificates shift cost from periodic renewal projects to ongoing operations. The recurring costs include running the CA and its automation, monitoring renewal jobs, rotating CA keys on a planned schedule, patching ACME clients and controllers, and handling exceptions when a platform cannot automate. Costs that are one-time include the initial inventory, integration work for each platform, and the design of the certificate hierarchy. Ask any partner to separate these items in the quote and to state who pays for ongoing support, upgrades and testing. Retainers for upgrades and monitoring are available from DeployOpen, and the scope of each should be agreed in writing.

How do we prevent outages from expired certificates?

Prevention relies on three controls working together: automated renewal well before expiry, independent expiry monitoring, and tested fallback steps. Automated renewal should start early in the validity window, so a single failure leaves time to act. Monitoring should come from a source separate from the issuing system, covering every endpoint in the inventory rather than only the certificates the CA knows about. Teams also need a runbook for failed renewals, covering who is paged, how to issue an emergency certificate, and how to confirm the reload worked. Ask a partner to demonstrate a simulated renewal failure during acceptance testing, because a monitoring setup that has never fired is unproven.

Questions to put to an implementation partner on certificate automation

Start with discovery, because automation only renews what it can see. Ask the partner how they will find certificates on load balancers, reverse proxies, Kubernetes clusters, cloud load balancers and managed services, and which of those they will not be able to read directly. Ask for the expected output of the inventory, including the fields it records (subject, issuer, serial, notAfter, key type and the owning service), and who signs off that the list is complete before renewal is switched on. For each target, ask which ACME client they will use, whether the target supports ACME natively or needs a hook, and how the partner will handle targets that support neither. Ask for a written list of gaps so the client can decide which services stay on manual renewal for now.

Next, ask what happens when the CA is unavailable. Ask how step-ca or OpenBao PKI is deployed for high availability, where the issuing keys live, how long a certificate can keep working if issuance stops, and how the partner will alert on that condition well before the oldest certificate reaches expiry. Ask how CA private keys are protected: whether step-ca will use an HSM, a cloud KMS or a YubiKey, which of those the client's security team has approved, and who holds the custody and backup procedure. Ask how the partner plans to reload services after renewal without restarts, and which targets will need a restart regardless, such as those that read certificates only at startup.

Finally, ask about the operating model. Ask how expiry monitoring is built, which thresholds trigger alerts, who receives them, and how the partner tests a renewal failure before it reaches production. Ask how long issuance and audit logs are retained, where they are stored and whether they can be exported to the client's SIEM. Ask how the partner handles licensing for OpenBao or HashiCorp Vault, since Vault 1.15.0 and later is licensed under the Business Source License 1.1 with IBM named as licensor, and OpenBao is licensed under MPL-2.0. Ask the partner to confirm in writing which license applies to each component in the proposed design and what changes if the client later needs a different version.

How DeployOpen scopes, builds and supports certificate automation

DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside your own infrastructure, so certificate automation for short-lived TLS runs in your cloud accounts, data centers or air-gapped networks. Each engagement starts from a written scope that covers the inventory, the issuance paths and the handover for moving toward 47-day certificates.

How we scope

Agree in writing which public and private certificates, domains and clusters are in scope before any work starts.
Document the current inventory sources, expiry visibility and owners so the starting point is measured, not assumed.
Confirm which services can accept ACME, which need a CA issuer and which require manual change windows.

How we build

Deploy the chosen CA and issuers, such as step-ca or cert-manager with an internal issuer, inside your environment.
Configure ACME renewal, certificate profiles and lifetimes for each service class, tested against staging endpoints first.
Test renewal failure paths, including CA unavailability and expired-certificate alerts, before workloads move to shorter lifetimes.

How we hand over

Deliver runbooks for issuance, renewal, revocation and CA key custody written for your own operations staff.
Provide the certificate inventory, configuration files and monitoring rules as documented, version-controlled artifacts.
Walk your platform and security teams through the renewal dashboards and the steps for a failed renewal.

How we support

Offer ongoing support, upgrades and testing as a retainer after handover, scoped separately from the build.
Review lifetime changes against the public schedule and plan rollouts for each new reduction stage.
Retest renewal and monitoring after platform upgrades, CA changes or new clusters are added.