Code Signing Certificates Must Now Carry a Reserved Policy OID

What ballot CSC-32 actually changed

Until version 3.11.0, a certificate authority could assert its compliance with the Code Signing Baseline Requirements in either of two ways: by including a CA/Browser Forum reserved policy OID, or by including a policy identifier of its own that it documented in its Certification Practice Statement. CSC-32 inverted that. The reserved OID became mandatory, and the CA’s own identifiers became the optional extra.

The new text in section 7.1.6.4 is one sentence: “Effective September 15, 2026 a Certificate issued to a Subscriber MUST contain exactly one of the reserved policy OIDs specified in Section 7.1.6.1 in the Certificate’s CertificatePolicies extension.” Everything else in the section survived intact, including the permission for a CA to assert additional identifiers of its own and the obligation to describe them in its CP or CPS.

The ballot was published on June 16, 2026 and passed without opposition: seven certificate issuers in favour (Actalis, Asseco Data Systems, which operates Certum, DigiCert, GlobalSign, HARICA, IdenTrust and Sectigo), Microsoft in favour on the certificate consumer side, no votes against and no abstentions. A unanimous ballot usually signals a cleanup rather than a fight, and that is roughly what this is. It closes a gap that had been sitting in the document since the Code Signing Baseline Requirements were adopted in 2015.

Why the gap mattered: if the reserved OID was optional, no piece of software could treat its absence as meaningful. A certificate without 2.23.140.1.3 might be a non-EV certificate, or it might be a perfectly good EV certificate from a CA that had chosen to assert its own OID instead. Any tool that wanted a reliable answer had to maintain a lookup table of per-CA policy numbers and keep it current. From September 15, 2026 the reserved value is guaranteed, so its absence in a new certificate means something definite.

The three reserved OIDs, and what each means

Section 7.1.6.1 defines three reserved certificate policy identifiers, and a subscriber certificate must now carry one of them. Two describe code signing certificates at the two validation levels the Requirements recognise, and the third describes a timestamping certificate, which is issued to a timestamp authority rather than to a software publisher.

The EV value looks out of place next to the other two, and it is. Read the arcs: 2.23.140.1.4.1 and 2.23.140.1.4.2 both hang off code-signing-requirements(4), while 2.23.140.1.3 hangs directly off the Forum’s certificate-policies(1) arc. That is a fossil from the years when EV code signing had its own separate guidelines document. Ballot CSC-25 folded that document into the Code Signing Baseline Requirements in 2024, but the OID kept the address it was registered at. If you are writing a parser, do not assume the EV value is a sibling of the other two. It is not, and a prefix match on 2.23.140.1.4 will silently miss every EV certificate.

Why “exactly one” is the phrase that matters

“Exactly one” applies to the reserved OIDs as a set, not to policy identifiers in general. A compliant certificate carries one, and only one, of the Forum’s three values, and may carry as many CA-defined identifiers alongside it as the CA cares to document. Most short summaries of the ballot collapse this into “one policy OID per certificate”, which is wrong and will break your validation logic if you code to it.

The two halves of the rule come from two adjacent paragraphs. Section 7.1.6.4 opens with the mandatory single reserved OID, and the very next paragraph says CAs “MAY also assert one or more policy identifier(s), defined by the CA”. So the shape of a compliant certificatePolicies extension is: one reserved value, plus zero or more CA values, in any order.

That last point is the one that catches people. If you add a hard requirement for a reserved OID to a signature verification gate today, every signature made with a certificate bought before this September starts failing, and those certificates are valid for up to 460 days from issuance. A certificate issued in February 2026 can still be signing code well into 2027 with no reserved OID in sight, entirely legitimately.

Does this affect a certificate you already hold?

No. Section 7.1.6.4 is an issuance rule, which means it constrains what a certificate authority may hand out from September 15, 2026 onward. It says nothing about certificates already in circulation. Yours keeps its original expiry date, keeps working in every tool that accepted it last week, and does not need to be reissued or replaced.

Signatures you have already produced are equally unaffected. A timestamped Authenticode signature stays verifiable after the signing certificate expires, and that behaviour is untouched here ; timestamping is governed by section 7.2 and the RFC 3161 mechanics, neither of which CSC-32 went near.

The change reaches you at renewal, and even then only as a difference in what the new certificate contains. There is no new paperwork, no new validation step, and no new hardware requirement. If you renew a code signing certificate in October 2026, the certificate that comes back will assert 2.23.140.1.4.1 or 2.23.140.1.3 where the one it replaced may not have.

How to read the policy OID out of a certificate

Export the public certificate and print its extensions. You do not need the private key, which matters because code signing keys have lived on hardware tokens or in cloud signing services since June 2023 and cannot be exported at all. Both of the commands below read a public certificate file and show the certificatePolicies extension.

With OpenSSL, on any platform:

openssl x509 -in codesigning.pem -noout -text

Look for the block that starts X509v3 Certificate Policies:. Each identifier appears on its own line beginning with Policy:, so an EV certificate from a CA that also asserts its own OID prints two such lines, one of them 2.23.140.1.3.

On Windows, without installing anything:

certutil -dump codesigning.cer

The same extension appears under Certificate Policies, with each policy numbered and its OID printed alongside any CPS qualifier the CA included. You can also reach it through the GUI on a signed file: right-click, Properties, Digital Signatures, select the signature, Details, View Certificate, Details, then scroll to Certificate Policies.

If you have only a signed binary and no certificate file, pull the certificate out of the signature first. Our walkthrough on verifying a code signature covers the extraction step on both Windows and Linux.

Who actually has to do something

Almost nobody who buys certificates. The work in CSC-32 lands entirely on certificate authorities, who had from June 16 to September 15, 2026 to adjust their issuance profiles. For software publishers this is a change you read about rather than act on. The one group that gains something concrete is the people who write code that inspects certificates.

The CI/CD row is where this quietly becomes useful. A release pipeline that wants to guarantee its artefacts were signed with an EV certificate has, until now, had to hard-code the policy OIDs of whichever CA it buys from and update that list whenever it switches supplier. From the cutover it can check for 2.23.140.1.3 and be done. If you are picking a validation level for a new project, our OV and EV code signing certificates are issued by Certum, whose parent Asseco Data Systems voted for this ballot, so the reserved OID lands in the certificate as described above.

Where CSC-32 sits in the schedule

CSC-32 is the third compliance date to hit code signing in three years, and by a distance the mildest. The June 2023 hardware key mandate ended software-only PFX files and forced every buyer onto a token, an HSM or a cloud signing service. The March 2026 validity cut took the maximum certificate lifetime from 39 months to 460 days. This one changes a field inside the certificate.

Grouping them that way is worth doing, because the first two are still generating support tickets and this one will not. If you are planning a renewal cycle, the 460-day limit in section 6.3.2 is the constraint that shapes it, and it is covered in detail in our piece on the 460-day code signing validity limit. CSC-32 changes nothing about your calendar.

As of September 15, 2026 the current version of the Code Signing Baseline Requirements is 3.11.0, and section 1.2.2 lists 2026-09-15 against section 7.1.6.4 in its table of relevant dates. That table is the fastest way to check whether a compliance date you half-remember is real, and it is worth a bookmark if you track this cluster of rules at all.