What changed

Microsoft published guidance on 20 August 2026, surfaced in the Windows message center on 21 August, on preparing the Windows ecosystem for next-generation code signing. The load-bearing fact is a date: Microsoft Windows Production PCA 2011 expires on 19 October 2026. Microsoft states it will transition Windows signing to a replacement certificate authority with the same security properties in the coming weeks, that signing moves to stronger configurations, RSA-3072 and SHA-384, by the end of 2026, and that Windows signing will transition to post-quantum signing in 2027. Windows itself is prepared for this; the guidance is aimed at software publishers, developers and the administrators who run their software. Microsoft names four ways an application can break when the certificate or the algorithm changes underneath it. It can pin certificate subjects, issuers, thumbprints or serial numbers, so verification fails the moment any of those values changes. It can require a fixed algorithm, such as SHA-256 or RSA-2048, and reject a signature made with a different one. It can parse signatures directly rather than validating trust through the Windows APIs, in which case it is relying on its own reading of a structure that is changing. Or it can maintain a private trust store that has not been updated for Microsoft’s certificate rotations. Microsoft’s remedy for developers is to validate trust through the Windows APIs, using WinVerifyTrust or the CryptoAPI interfaces, to remain algorithm-agnostic, to test against the replacement certificates and SHA-384 signatures, and to keep private trust stores current. Its remedy for administrators is shorter and is not technical: ask your critical software vendors those same questions.

The operational risk is easy to miss because the service can continue to look healthy. The control becomes visible only when a capacity request fails, an unsupported runtime is removed, or an extension blocks an enforced ERP update. Waiting for that moment transfers a planned decision into an incident.

What the term means in plain language

Code signing attaches a cryptographic signature to software so that Windows can confirm who published it and that it has not been altered. A certificate authority is the issuer that vouches for the signing certificate, and Microsoft Windows Production PCA 2011 is the intermediate authority behind Windows production signatures. Pinning is the practice of hard-coding an expected certificate detail, such as a thumbprint, subject, issuer or serial number, so that verification succeeds only against that exact value. A private trust store is an application’s own list of trusted certificates, maintained separately from the Windows certificate stores. Post-quantum cryptography refers to algorithms designed to remain secure against attacks by future quantum computers, and Microsoft has stated Windows signing moves to post-quantum signing in 2027.

This distinction matters because product status is not the same as business readiness. Availability, support and compatibility are separate questions. A service can be available but unsupported, supported but capacity-constrained, or technically updated while a customer-specific process has stopped working.

Why this matters to a South African organisation

South African teams often operate with tight specialist capacity, rand-sensitive budgets and business processes that cannot be paused while a replacement is sourced. Localisation, regional cloud capacity and long procurement lead times can narrow the recovery options. The practical response is to use the available test window before it becomes an emergency window.

The consequence belongs to the business process, not only the technology team. Finance month-end, customer transactions, data pipelines and ERP extensions all cross technical and operational ownership. A change should therefore be accepted only when the service owner and the business owner can see the same evidence.

The hidden exposure

Microsoft Windows Production PCA 2011, the certificate authority behind Windows code signatures, expires on 19 October 2026, with a replacement arriving in the coming weeks and stronger signing configurations following by the end of 2026. Windows handles the change. The risk sits in third-party applications that pin certificate details, demand a specific algorithm, parse signatures themselves, or keep a private trust store nobody updates. The action is a question to your software vendors, and their answer is not under your control.

Normal operation is weak evidence. It proves only that yesterday’s combination of platform, configuration and workload completed. It does not prove that the next capacity allocation, lifecycle enforcement or major release will preserve the same result. An owner needs an inventory, a representative test and a dated decision.

Decision path

There is no configuration change to make here, which is exactly why it gets left. The work is procurement and follow-up, and it is slow because the answers come from other organisations. That is the reason to start it in August for a date in October rather than treating an eight-week horizon as comfortable. Think about which software is actually exposed. It is rarely the current, actively developed products. It is the long-lived line-of-business application that has been running unchanged for years, the security or backup agent that inspects signatures as part of its own job, the specialist package a regulator or an insurer required, and anything built in-house by a developer who has since left. Those are the applications most likely to contain a hard-coded expectation, and least likely to have anyone actively testing against Microsoft’s replacement certificates. Braintree’s view, not Microsoft’s, is that the failure mode is what makes this expensive rather than the failure itself. When a signature check fails inside an application, the symptom a user reports is that something which worked yesterday will not start, or will not update, and the error text will rarely mention a certificate. That ticket gets routed as an application problem, investigated as an application problem, and the certificate change is found late, by which time several similar tickets are open. A dated list of vendor answers turns that investigation from a day into a question. Keep the answers in writing, because the value is not only in the reassurance. A vendor who cannot answer whether their product pins Microsoft certificates is telling you something useful about how much attention that product still gets, and that is worth knowing before October rather than during it. Where a product has no vendor left to ask, that is not an answer, it is a finding, and it belongs on a risk register with a named owner.

Record the alternatives that were rejected and why. That prevents the next reviewer from reopening the entire question without context. Where the preferred path cannot be completed inside seven days, approve a time-bound exception with a responsible owner, expiry date and compensating control.

Technical test plan

Build the list first, and keep it short enough to actually work through: the applications whose failure would stop a business process the same day. For each one, send Microsoft’s questions to the vendor’s support or account contact in writing rather than raising them in a call, so the answer is retained. Where you build or maintain software yourselves, the same questions are an internal code review: search for hard-coded thumbprints, subject or issuer strings and serial numbers in verification paths; look for algorithm identifiers such as SHA-256 or RSA-2048 written into validation logic; identify any code that parses signature structures directly instead of calling WinVerifyTrust or the CryptoAPI interfaces; and locate any private trust store the application ships with, along with whatever process is meant to keep it current. Microsoft’s direction for all four is the same: validate trust through the Windows APIs and stay algorithm-agnostic, so that a certificate or algorithm change is absorbed rather than rejected. Plan a test window once the replacement certificates are available, prioritising anything that inspects signatures as part of its function, since those applications encounter the change first and most often. Note carefully what this guidance does not say: it does not mention Windows Update, driver installation or Secure Boot, and nothing about those should be inferred from it. Windows has separate Secure Boot certificate work under way on its own timeline, and treating the two as one change is the fastest way to produce a plan that is wrong about both.

Use production-representative conditions without exposing production data unnecessarily. Capture the starting configuration, exact version, time of test and expected result. A pass requires evidence from the real workflow, not only a successful login or an unchanged dashboard.

Primary owner

Primary owner: The IT manager accountable for the software estate, with the commercial owner of each critical vendor relationship.

The named owner coordinates platform, application, commercial and business-process decisions. Contributors may perform the work, but accountability cannot be distributed across a meeting invite. The owner closes the test, exception and evidence record.

Action within seven days

Action within seven days: Send Microsoft’s own questions to every critical software vendor this week, and record the answers. Do their applications use the supported Windows trust APIs. Do they pin Microsoft certificates or certificate authorities. Have they tested against the replacement Microsoft signing certificates and SHA-384 signatures. Do they maintain a private trust store, and what is the process that updates it. Do they have a plan for the post-quantum signing changes coming in 2027.

Start with the highest-consequence workload. Assign the people, date and pass criteria before the test begins. If the first test fails, record the failure as evidence and open remediation with a deadline rather than hiding it behind a general project status.

Evidence to retain

Evidence to retain: The dated list of critical applications with the vendor contacted, the date of contact and the written answer to each question. Add the internal equivalent for any software your own developers build or maintain, and a short note of which applications have no vendor to ask, since those are the exposures with no owner.

Store the evidence with the platform or change record. Include source exports and machine-readable results where possible. The next reviewer should be able to reproduce the conclusion without rebuilding it from email, chat or memory.

Frequently asked questions

What exactly expires, and when?

Microsoft Windows Production PCA 2011, on 19 October 2026. Microsoft states it will transition Windows signing to a replacement certificate authority with the same security properties in the coming weeks.

Will Windows stop working?

No. The guidance is about applications running on Windows, not about Windows itself. Microsoft is managing the transition of its own signing.

What breaks?

Applications that pin certificate subjects, issuers, thumbprints or serial numbers; that require a fixed algorithm such as SHA-256 or RSA-2048; that parse signatures directly instead of using the Windows APIs; or that maintain a private trust store that is not updated for Microsoft certificate rotations.

What does a failure look like?

Braintree’s description, not Microsoft’s: something that worked previously refuses to run or refuses to update, and the error is unlikely to name a certificate. Expect it to arrive as a ticket about an application rather than about Windows.

What are we supposed to do about it?

Ask your critical software vendors Microsoft’s questions and keep the answers. Microsoft’s administrator guidance is to ask whether applications use supported Windows trust APIs, pin Microsoft certificates or certificate authorities, have been tested with the replacement signing certificates and SHA-384 signatures, maintain a private trust store with a certificate-update process, and have a plan for future post-quantum signing changes.

Are the algorithms changing too?

Yes. Microsoft states signing moves to stronger configurations, RSA-3072 and SHA-384, by the end of 2026, and to post-quantum signing in 2027. An application that demands one specific algorithm is exposed to that change as well as to the certificate change.

Does this affect Windows Update or Secure Boot?

The guidance does not mention Windows Update, driver installation or Secure Boot. Secure Boot certificate work is a separate change on its own timeline and should be planned separately.

The Braintree view

Microsoft’s announcement supplies the platform fact. The customer control begins after that fact: identify the exposed process, name the owner, test the real dependency and retain a decision that can survive audit or staff turnover. Braintree can help structure the inventory, build the representative test and translate the result into a controlled implementation plan.

Use the seven-day action as the entry point. Do not wait for a renewal, support refusal or enforced update to reveal work that can be measured now.