Skip to content

March 2026 update #20

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
kasirota wants to merge 5 commits into
base: main
Choose a base branch
from
Open

March 2026 update #20

Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
ee280a2
Limit EKU Scope for new roots
kasirota Mar 4, 2026
c461f45
Revise validity period for newly minted Root CAs
kasirota Mar 11, 2026
c2708da
Suspect Code Definition
kasirota Mar 11, 2026
2f58a9d
Add incident reporting requirement for CAs
kasirota Mar 11, 2026
5d72063
Merge pull request #19 from kasirota/main
kasirota Mar 11, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 12 additions & 1 deletion Requirements.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -52,6 +52,8 @@ The Microsoft Trusted Root Program enables customers to trust Windows products b

**2.1.17.** Certificate Authorities MUST update their Certificate Policy (CP) and Certification Practice Statement (CPS) documents before applying any change in operations. The updated documents must be made publicly available and communicated to Microsoft. CAs should provide these updates by updating the CCADB. CAs MUST update the changelog in their CP/CPS documents with what changes were made.

**2.1.18** Certificate Authorities MUST publicly disclose and/or respond to incident reports in Bugzilla, including incidents that the Program Participant believes to be low‑impact, procedural, or non‑security‑relevant. Incident reports MUST be submitted in accordance with the current CCADB Incident Report format and applicable disclosure timelines, which can be found here: <https://www.ccadb.org/cas/incident-report>. If a Program Participant has not yet publicly disclosed an incident in Bugzilla, the Participant MUST promptly notify msroot [at] microsoft.com and MUST provide an initial public disclosure timeline.



## 3. Program Technical Requirements
Expand All @@ -71,7 +73,7 @@ The Microsoft Trusted Root Program enables customers to trust Windows products b

**3.1.7.** Root Key Sizes must meet the requirements detailed in "Signature Requirements" below.

**3.1.8.** Newly minted Root CAs must be valid for a minimum of eight years, and a maximum of 25 years, from the date of submission.
**3.1.8.** Newly minted Root CAs must be valid for a maximum 10 years, from the date of submission, effective July 1, 2026.
Copy link

@XolphinMartijn XolphinMartijn Mar 17, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems this requirement limits the usage of cross-signing chains, leading to breakage on devices older than 10 years old. I'm just wondering if this is also an intended outcome?


**3.1.9.** Participating Root CAs may not issue new 1024-bit RSA certificates from roots covered by these requirements.

Expand Down Expand Up @@ -148,8 +150,12 @@ The Microsoft Trusted Root Program enables customers to trust Windows products b
### 3.3. Code Signing Root Certificate Requirements

**3.3.1.** Root certificates that support code signing use may be removed from distribution by the Program 10 years from the date of distribution of a replacement rollover root certificate or sooner, if requested by the CA.

**3.3.2.** Root certificates that remain in distribution to support only code signing use beyond their algorithm security lifetime (e.g. RSA 1024 = 2014, RSA 2048 = 2030) may be set to 'disable' in a future release.

**3.3.3** For clarity and transparency, Microsoft and the Microsoft Trusted Root Program classify “suspect code” using the same criteria applied across Microsoft security products. These classifications are documented in Microsoft’s Unified Security Operations criteria, which describe how Microsoft identifies and categorizes malware, potentially unwanted applications, tampering software, and related behaviors: <https://learn.microsoft.com/en-us/unified-secops/criteria>. These definitions are provided to assist Program Participants in understanding how Microsoft may assess code behavior during incident investigation, disclosure, and enforcement activities.


### 3.4. EKU Requirements

**3.4.1.** CAs must provide a business justification for all of the EKUs assigned to their root certificate. Justification may be in the form of public evidence of a current business of issuing certificates of a type or types, or a business plan demonstrating an intention to issue those certificates in the near term (within one year of root certificate distribution by the Program).
Expand All @@ -162,6 +168,11 @@ The Microsoft Trusted Root Program enables customers to trust Windows products b
5. Document Signing EKU=1.3.6.1.4.1.311.10.3.12
- This EKU is used for signing documents within Office. It isn't required for other document signing uses.

**3.4.3** Effective for all root certificates submitted on or after July 1, 2026:
Effective for all root certificates submitted on or after July 1, 2026, root certificates MUST be limited in scope and dedicated to a clearly defined trust purpose.
Copy link
Contributor

@dzacharo dzacharo Mar 12, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Considering that the id-kp-clientAuth KeyPurposeId is allowed further below, please consider making the following change:

Suggested change
Effective for all root certificates submitted on or after July 1, 2026, root certificates MUST be limited in scope and dedicated to a clearly defined trust purpose.
Effective for all root certificates submitted on or after July 1, 2026, root certificates MUST be limited in scope and dedicated to clearly defined trust purposes.

Root certificates authorized for Server Authentication, S/MIME, or Code Signing MUST each be separate and independent trust anchors. A root certificate MUST NOT be authorized for more than one of these EKUs.
A root certificate authorized for Code Signing MAY also be authorized for Client Authentication and Time Stamping. A root certificate authorized for Server Authentication OR SMIME MAY also be authorized for Client Authentication.
No EKU combinations other than those explicitly permitted above are allowed.Root certificates submitted prior to January 1, 2027 that assert multiple EKUs will continue to be trusted unless otherwise directed by Microsoft.

# 4. Audit requirements

Expand Down