TLS Certificates Drop to 100 Days in March 2027. Can Your Asset Register List Them?

Most security deadlines arrive as a consultation, a speech or a draft Bill, and the honest advice is usually to wait and see. This one is different. The schedule is already running, the first step took effect six months ago, and the organisations that enforce it have already voted.

From 15 March 2026, publicly trusted TLS certificates have been capped at 200 days. From 15 March 2027 the cap falls to 100 days. From 15 March 2029 it falls to 47 days, and the period for which a certificate authority may reuse your domain validation data falls to 10 days.

Ballot SC-081v3 was adopted in April 2025. Certificate issuers voted 25 in favour and none against. Certificate consumers voted 4 in favour and none against, and those four are Apple, Google, Microsoft and Mozilla. There is no authority left to appeal to.

The operational consequence is simple arithmetic. A certificate you renew once a year today becomes roughly four renewals a year in 2027, and roughly eight in 2029. Whatever you are doing by hand now, you will be doing it eight times as often.

The part nobody has a list of

Here is the awkward question, and it is the one I would ask in an audit.

Show me every publicly trusted certificate your organisation is responsible for, with its owner, its expiry date and what breaks when it expires.

In most organisations that list does not exist. There is a renewal reminder in somebody’s calendar, a wildcard certificate whose original requester has left, a certificate on a marketing microsite nobody remembers commissioning, and a handful on appliances that were configured once during installation.

None of that is unusual. What makes it a finding is that an auditor can test it from the outside in about ten minutes, using public certificate transparency logs, without any access to your environment. Certificate transparency means every publicly trusted certificate issued for your domains is a matter of public record. If your internal list is shorter than the public one, the gap is the finding, and you did not get to choose how it was discovered.

That is a different class of problem to most inventory gaps, which only surface when somebody inside goes looking.

A certificate is two things in Annex A at once

This is where it stops being an IT housekeeping task and becomes a management system question.

A.5.9, inventory of information and other associated assets. A certificate is an associated asset. It has an owner, a location, a lifecycle and a disposal date. If your inventory stops at laptops and servers, it is not doing the job the control describes, which is the same argument we made about the components inside your software in the assets nobody put on the register.

A.8.24, use of cryptography. A certificate is the public half of a key pair, so it also sits under the cryptography control, which covers key management across the full lifecycle including generation, storage, renewal and revocation. That is what the industry means by certificate lifecycle management, and an organisation with a cryptography policy that says nothing about who renews certificates and how has written a policy about algorithms and forgotten the operational half.

The two controls read differently and point at the same object. That is usually a sign the object matters.

An expired certificate is an availability incident

Security people tend to file certificates under confidentiality, because that is what TLS protects. The failure mode is the opposite.

When a certificate expires, nothing is disclosed. The service simply stops being reachable, browsers refuse the connection, integrations fail, and the failure is total rather than degraded. It affects every user at once, and it affects them in a way that looks to a customer exactly like a compromise, because their browser shows a security warning.

That puts it squarely inside A.5.29, information security during disruption, and A.5.30, ICT readiness for business continuity, and it makes it an incident under A.5.24 to A.5.27. It is worth checking whether your business impact analysis has ever contemplated it. Most contemplate a data centre, a supplier and a cyber attack. Very few contemplate a date passing.

It is also one of the very few availability risks that comes with a calendar attached. You cannot know when a supplier will fail. You can know exactly when a certificate will.

What stops organisations automating is the estate underneath

The obvious answer to a 47 day renewal cycle is automation, and the protocols to do it have existed for a decade. So why does anyone still renew certificates by hand?

A DigiCert survey of technology decision-makers reported this month puts the most common barrier as legacy technology. Treat the figure itself with the caution any vendor survey deserves, but the direction is not controversial: automated renewal requires a system that can be told to accept a new certificate without a human logging in, and a great deal of Australian infrastructure cannot.

That connects this to something the head of the Australian Signals Directorate said last week. Abigail Bradshaw was reported as telling an ASPI event on 14 September that Australia is sitting on an enormous legacy technology debt, and that the most powerful response available is to set legacy technology reduction targets and move towards them.

ASD has written the detail down. Its Managing the risks of legacy IT guidance uses the Protective Security Policy Framework definition, and that definition is more precise than most people expect. A product is legacy when it meets a criterion from both of two categories:

• Category A: it is end-of-life, or out of support including extended support.
• Category B: it is impractical to update or support in-house, or no longer cost-effective, or above your acceptable risk threshold, or offers diminishing business utility, or obstructs your IT strategy.

Two categories, not one. A supported product that has become expensive is not legacy. An unsupported product that still does its job perfectly well is.

ASD is blunt about the treatment. Replacement with supported technology is the only thing that eliminates the risk. Where replacement is not yet feasible, temporary mitigations reduce some of it. And the guidance names what most registers are missing:

developing an accurate register of all IT in your organisation, if there is not one already … maintaining that IT register, and regularly monitoring your organisation’s IT environment to ensure the IT is still vendor supported

Read that as an auditor and it is A.5.9 with one extra column. Not just what you own, but whether what you own is still supported, and until when. Almost no asset register I am shown carries that column, and without it an organisation cannot state its own legacy exposure, let alone reduce it.

ASD also makes a point worth repeating to anyone who treats this as a one-off cleanup: all IT becomes legacy eventually. It is a continuous control, not a project.

What the certificate schedule and the legacy estate have in common

They are the same problem viewed from two ends.

The certificate schedule gives you a dated, external, non-negotiable requirement to renew more often. The legacy estate is the reason you cannot meet it cheaply. An organisation that responds to 2027 by hiring more manual effort has treated a structural problem as a staffing one, and will meet 2029 in worse shape.

ASD’s own case study shows where the other end leads. In April 2022 a New South Wales council was compromised through a legacy entry point that no longer received vendor support and that the council could not maintain itself. Ransomware encrypted council minutes, employee financial data and water quality monitoring systems. Staff worked between 40 and 80 hours of overtime in a week, a commercial incident response provider was engaged, and water quality had to be monitored manually for weeks afterwards.

Nothing in that story required a sophisticated attacker. It required something unsupported, left in place.

Where the objective goes

Bradshaw’s phrase was reduction targets, and in a management system a target with a date and an owner has a specific name.

Clause 6.2, information security objectives, requires objectives that are measurable where practicable, monitored, communicated and updated. That is exactly the shape of “every publicly trusted certificate under automated renewal before 15 March 2027”, or “no internet-facing system running out-of-support software by 30 June”. Both are measurable, both carry a date that came from outside the organisation, and neither is a platitude.

• Clause 7.1, resources. An objective with no budget is a wish. Legacy replacement is the clearest case there is of a control that fails for want of funding rather than want of knowledge.
• Clause 9.1, monitoring and measurement. Percentage of certificates under automated renewal, count of unsupported products in service, and how both moved.
• Clause 9.3, management review. ASD’s guidance tells security leads to convey legacy risk to business groups and corporate risk processes. Management review is where an ISMS does that on the record.
• Clause 9.2, internal audit. The test that matters is sampling the register against reality: pull the certificate inventory and compare it with what is serving on the organisation’s public domains.

We made the same case for turning an external metric into a defensible objective in what your Microsoft Secure Score makes a SMARTER objective. The mechanism is identical. Something external and numeric becomes something internal, owned and reviewed.

What an auditor asks for

If I were auditing this tomorrow, this is the thread I would pull. It works as a self-test whether or not anyone is coming.

1. The list. Every publicly trusted certificate, with owner, expiry and the service it protects. Produced from a system, not from memory.
2. The comparison. That list against what certificate transparency says was issued for your domains. Explain the difference.
3. The renewal path. For each one, automated or manual. If manual, who, and what happens when they are on leave in March.
4. The support column. Your asset register, showing support status and end-of-support date. If the column does not exist, that is the answer.
5. The treatment. For anything unsupported, either a dated retirement plan or documented compensating controls. Not silence.
6. The objective. Where the reduction target lives, who owns it, and what the last measurement said.
7. The loop. Whether any of the above reached management review, and whether anything changed as a result.

Points 2 and 4 are where most systems come apart, and they are the same failure: the register describes what somebody remembers rather than what exists.

Where this comes unstuck

Treating it as the IT team’s problem. Certificate expiry and legacy replacement both fail on budget and ownership, which are management system questions rather than technical ones.

A wildcard certificate as the fix. One certificate across many services concentrates the failure instead of removing it, and it still expires on the same schedule.

Counting only the certificates you bought. Certificates arrive through cloud platforms, CDNs, load balancers and SaaS vendors configured on your domains. The public log does not care who purchased them.

Automating renewal and not monitoring it. An automated renewal that silently stops working is worse than a manual one somebody remembers, because nobody is watching the calendar any more.

Writing the objective without the money. Clause 7.1 exists for this. An objective to retire unsupported systems, set without a replacement budget, will be carried forward at every management review until something happens that settles it for you.

Frequently asked questions

Does the 47 day limit apply to internal certificates?

No. The Baseline Requirements govern publicly trusted certificates, the ones issued by certificate authorities that browsers trust by default. A private internal certificate authority sets its own policy. That said, the operational argument for automation applies equally, and your internal certificates belong on the same register.

Is 47 days confirmed, or could it change?

It sits in the Baseline Requirements with an effective date of 15 March 2029. Ballot SC-081v3 was adopted with no votes against from either certificate issuers or the browser vendors who enforce it. Standards can be amended, but nothing about the current position suggests reversal.

What is the immediate deadline?

15 March 2027, when the cap falls to 100 days. The 200 day cap has applied since March 2026.

Does ISO 27001 require certificate automation?

No. ISO 27001 does not prescribe technical solutions. It requires you to know what assets you hold (A.5.9), manage cryptographic keys across their lifecycle (A.8.24), and set measurable objectives where practicable (clause 6.2). Whether you meet a 47 day cycle by automation or by staffing is your decision to make and to justify.

What counts as legacy technology?

Under the definition ASD uses, a product must meet a criterion from both categories: end-of-life or out of support, and impractical to maintain, uneconomic, above your risk threshold, of diminishing utility, or obstructive to your IT strategy.

We have an asset register. Is that enough?

Only if it records support status and end-of-support date. Without those columns it lists what you own but cannot tell you what you are exposed to.

Knowing what you hold

Both halves of this come down to the same sentence: an organisation cannot manage what it has never listed.

Streamline builds and audits ISO 27001 information security management systems for Australian organisations, and you deal directly with a practising ISO Lead Auditor. A gap analysis is the usual way to find out what your register is missing, an independent internal audit under clause 9.2 tests whether it matches reality, and ISO mentoring is the option where you would rather your own people did the building.

Start with one question. Pull your certificate list, compare it with what is publicly logged against your domains, and see whether the two agree. If they do not, get in touch.

Sources

• CA/Browser Forum, Baseline Requirements for publicly trusted TLS server certificates, effective dates for sections 6.3.2 and 4.2.1
• CA/Browser Forum, Ballot SC-081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods, adopted April 2025, including voting results
• Australian Signals Directorate, Managing the risks of legacy IT: Executive guidance, June 2024
• Abigail Bradshaw, Director-General ASD, reported remarks at an ASPI event, 14 September 2026
• DigiCert Certificate Management Outlook, vendor survey, reported September 2026

General information from an auditing and management system perspective, current at 21 September 2026. Not legal advice, and not technical advice on a specific environment.