As enterprise security needs grow more complex and digital threats evolve, Microsoft continues to adapt its security framework accordingly. With the recent overhaul in Application Control for Business—formerly known as Windows Defender Application Control (WDAC)—organizations now face significant changes in how Windows authenticates code and manages trust for critical system components. These updates, rolling out from mid-2025, aim to modernize certificate authority (CA) handling in preparation for the expiration of longstanding Microsoft issuing CAs. This article examines the new certificate authority handling logic, explores the practical implications for business and IT administrators, and scrutinizes both the strengths and potential risks associated with this major transition.
Historically, this trust has relied on a set of Microsoft’s intermediate CAs, with certificates lasting up to 15 years. As these CAs approach their expiration—some as soon as July 2025—the risk of disruption grows unless both Microsoft and its customers adapt to new signing infrastructure.
Each expiring CA is being replaced by a new CA, issued either in 2023 or 2024. For example, Microsoft Code Signing PCA 2010 will be replaced by Microsoft Windows Code Signing PCA 2024, with its own unique TBS (To-Be-Signed) hash.
A comprehensive cross-reference between old and new CAs is now critical for organizations using Application Control to ensure uninterrupted software deployment and updates.
This inferencing means that if a policy includes a rule to trust Windows Production PCA 2011, it will also extend trust to Windows Production PCA 2023, using the new TBS hash without administrative intervention. This applies to both allow and deny rules, helping organizations maintain uninterrupted enforcement as old CAs are retired.
Example:
This widespread availability means that the inferencing logic is consistent across diverse environments, dramatically reducing the risk of fragmented security policy behavior across an organization’s device estate.
The inferencing model ensures that trust (and deny) logic automatically stays in sync with Microsoft’s updated CA infrastructure. This is especially valuable during the rapid sunset of multiple 15-year CAs, as it prevents lapses in application allowlisting or vulnerability exploitation due to out-of-date trust anchors.
However, as with any abstraction layer, administrators cede some direct visibility and control. Security teams must remain vigilant, validating that the inferencing behaves as advertised—especially in high-stakes or regulated environments.
Independent review of Microsoft’s mapping between old and new CAs is also advisable. Though the company’s documentation and Servicing Stack updates are detailed and comprehensive, no system is immune to oversights, especially when trust boundaries underpin the entire executable verification process.
For organizations with security policies aligned closely to NIST, ISO, or industry-specific compliance frameworks, the default inferencing logic will generally align with best practices—but must be validated in context, especially where custom root-of-trust models are in play.
Still, this period represents a critical window for all organizations using Windows Application Control to review, audit, and refine their security policies, ensuring they not only avoid disruption as the CA infrastructure evolves, but also leverage contemporary best practices in application allowlisting and code authentication.
For most organizations, embracing the new inferencing logic promises to reduce migration headaches and head off threats posed by expiring certificates—a rare win-win in the sometimes frustrating world of enterprise security compliance. Nonetheless, success hinges on vigilance, timely updates, and open communication between IT administrators and Microsoft as the rollout continues.
In closing, as enterprises worldwide rely on consistent, predictable software security, the work done now to understand and implement these changes in Application Control for Business will pay dividends not just in continuity, but in resilience against an increasingly hostile threat landscape.
Source: Microsoft - Message Center Windows support for the Application Control for Business new CA handling logic - Microsoft Support
The Evolution of Application Control and CA Trust Management
What is Application Control for Business?
Application Control for Business is Microsoft’s premier solution for maintaining application integrity, preventing untrusted code execution, and strictly controlling what software can run within a Windows environment. In heavily regulated industries and high-security deployments, Application Control (previously WDAC) is not just a feature—it’s often a necessity. It uses a combination of policy enforcement, digital signatures, and, crucially, certificate chain trust to determine whether code is allowed or blocked at runtime.The Role of Certificate Authorities in Windows Security
Within the Windows ecosystem, certificate authorities (CAs) underpin the trust model that allows organizations to confidently execute software updates and run critical applications. Microsoft’s own issuing CAs are responsible for signing Windows components and related binaries. Trust in these certificate chains is enforced using “signer rules”—elements of Application Control policy that specify which certificates, publishers, or code attributes are trusted or denied.Historically, this trust has relied on a set of Microsoft’s intermediate CAs, with certificates lasting up to 15 years. As these CAs approach their expiration—some as soon as July 2025—the risk of disruption grows unless both Microsoft and its customers adapt to new signing infrastructure.
The 2025 CA Transition: What’s Happening
Expiry and Replacement of Microsoft Issuing CAs
Microsoft has outlined that its existing intermediate CAs, responsible for signing core Windows and related components, will begin expiring in a staged schedule starting July 2025. The relevant CAs and their expiration dates are:Expiring CA Name | TBS Hash (Short) | Expiration Date |
---|---|---|
Microsoft Code Signing PCA 2010 | 121AF4B9...8195 | July 6, 2025 |
Microsoft Windows PCA 2010 | 90C96696...05212 | July 6, 2025 |
Microsoft Code Signing PCA 2011 | F6F717A4...BF26E | July 8, 2026 |
Windows Production PCA 2011 | 4E80BE10...32146 | Oct 19, 2026 |
Microsoft Windows Third Party Component CA 2012 | CEC1AFD0...2DD46 | Apr 18, 2027 |
A comprehensive cross-reference between old and new CAs is now critical for organizations using Application Control to ensure uninterrupted software deployment and updates.
New Application Control Logic: Automatic Trust Inferencing
Transparent Trust Migration
One of the most significant innovations in this update is that Application Control for Business policies containing signer rules with TBS hashes for the outgoing CAs do not require manual updating to trust binaries signed by the new CAs. Instead, Application Control will automatically “infer” trust relationships for the replacements.This inferencing means that if a policy includes a rule to trust Windows Production PCA 2011, it will also extend trust to Windows Production PCA 2023, using the new TBS hash without administrative intervention. This applies to both allow and deny rules, helping organizations maintain uninterrupted enforcement as old CAs are retired.
Example:
- A policy containing:
Code:<Signer ID="ID_SIGNER_WINDOWS_CA_1" Name="Microsoft Windows Production PCA 2011"> <CertRoot Type="TBS" Value="4E80BE107C860DE896384B3EFF50504DC2D76AC7151DF3102A4450637A032146" /> <CertEKU ID="ID_EKU_WINDOWS" /> </Signer>
Code:<Signer ID="ID_SIGNER_WINDOWS_CA_2" Name="Windows Production PCA 2023"> <CertRoot Type="TBS" Value="34EEC0CD7321C9C20309BEF31164D92B88E892341DE67FE2684D9E7FDA09C9E46B05498FB38E29B421E845FEB8C7A4CD" /> <CertEKU ID="ID_EKU_WINDOWS" /> </Signer>
Automatic Extension to Deny Rules
Deny signer rules are treated with the same inferencing process. Components previously denied based on signatures from the outgoing CAs will continue to be denied if they are now signed by the new 2023/2024 CAs. There is no need to duplicate or rework complex policy logic, greatly reducing administrative overhead and risk of accidental security loopholes during the migration.Compatibility and Platform Support
Broad Backporting of New Logic
Microsoft has rolled out this updated TBS hash inferencing logic via servicing updates to all supported Windows platforms equipped with Application Control. This means enterprises running everything from Windows 10 (version 1607 and higher) to Windows Server 2025 will receive these changes as part of recent security or cumulative updates. The relevant KBs and OS builds are:Windows OS | Date/KB ID | OS Build |
---|---|---|
Windows Server 2025 | KB5058411 (May 13, 2025) | 26100.4061 |
Windows 11, version 24H2 | KB5055627 (Apr 25, 2025, Preview) | 26100.3915 |
Windows Server, version 23H2 | KB5058384 (May 13, 2025) | 25398.1611 |
Windows 11, version 22H2/23H2 | KB5055629 (Apr 22, 2025, Preview) | 22621.5262/22631.5262 |
Windows Server 2022 | KB5058385 (May 13, 2025) | 20348.3692 |
Windows 10, versions 21H2/22H2 | KB5058379 (May 13, 2025) | 19044.5854/19045.5854 |
Windows 10, version 1809/Server 2019 | KB5058392 (May 13, 2025) | 17763.7314 |
Windows 10, version 1607/Server 2016 | KB5058383 (May 13, 2025) | 14393.8066 |
Administrative Controls and Opt-Out Mechanism
For organizations with highly custom compliance or audit needs, Microsoft offers a way to opt-out of the automatic TBS hash inferencing logic. If required, administrators can disable this behavior via specific policy flags, reverting to manual management of certificate trust lists. While Microsoft does not recommend disabling inferencing by default, this flexibility is important for enterprises in regulated sectors or with bespoke trust models.Benefits and Strengths of the New Approach
Seamless Security and Reduced Administrative Overhead
Perhaps the most significant advantage of the new CA handling logic in Application Control is reduced operational complexity. There is no longer a need to proactively update policies or signers as CAs transition, which previously might have required extensive changes, emergency maintenance windows, and significant QA/testing resources.The inferencing model ensures that trust (and deny) logic automatically stays in sync with Microsoft’s updated CA infrastructure. This is especially valuable during the rapid sunset of multiple 15-year CAs, as it prevents lapses in application allowlisting or vulnerability exploitation due to out-of-date trust anchors.
Minimizing Deployment Risk During the Migration Window
Enterprises often cite the risk of sudden certificate expiration as a potential source of costly downtime, software deployment failures, or false security positives. By architecting a system that bridges both the old and new CA trust anchors seamlessly, Microsoft significantly reduces the exposure to these issues—even as thousands of applications, drivers, and Windows updates are migrated to be signed by the new CAs.Backward Compatibility and Future-Proofing
By servicing all supported Windows releases, Microsoft ensures that even legacy environments still receive the benefits of the new logic. This approach ensures that organizations who are not yet able to fully transition to the latest OS builds remain protected and operational throughout the certificate infrastructure upgrade lifecycle.Transparent Policy Logic for Compliance
Because Application Control preserves signer-specific details during inferencing, compliance reporting and security audits benefit from transparent, predictable trust relationships. Policy rules continue to reference expected publishers, key usages, and file attributes—simply extended to the new CAs, without the need for manual mapping or documentation updates.Potential Risks and Caveats
Dependency on Microsoft’s Trust Logic
Organizations should note that this inferencing mechanism relies fundamentally on Microsoft’s accurate mapping between outgoing and new CAs. If a mapping is incomplete, erroneous, or delayed, there is risk of either inadvertently allowing untrusted code or mistakenly blocking legitimate signed binaries. While there is currently no evidence to suggest such errors have occurred, security teams are advised to watch Microsoft’s advisory channels for guidance and potential updates.Reduced Granularity for Power Users
Some highly security-conscious enterprises may wish to exert explicit control over exactly which CAs are trusted or denied, rather than inheriting trust decisions from Microsoft’s mapping. While opt-out is supported, it adds a layer of manual management that can increase administrative workload and oversight risk. Organizations must carefully weigh the cost/benefit of this tradeoff in their security governance approach.Legacy Devices and Unsupported Systems
As always, devices running unsupported or end-of-life Windows versions will not receive the new inferencing logic. For these systems, trust relationships must be updated manually to avoid disruption as certificates expire. This is a significant risk vector for environments with unmanaged, legacy, or embedded devices.Documentation and Policy Complexity
Despite the streamlined process, Application Control policy files and documentation may still become complex, particularly for organizations using mixed explicit and inferred signer rules. Security teams must ensure documentation is kept up to date and that incident response teams are trained to interpret trust relationships in the context of both legacy and new certificate infrastructure.Critical Analysis: Balancing Automation and Control
Microsoft’s approach to updating CA handling logic reflects a broader security trend: use automation to reduce human error, but preserve explicit control for those who need it. In theory, seamless trust inferencing vastly simplifies the transition and lowers risk of unplanned outages or failed deployments.However, as with any abstraction layer, administrators cede some direct visibility and control. Security teams must remain vigilant, validating that the inferencing behaves as advertised—especially in high-stakes or regulated environments.
Independent review of Microsoft’s mapping between old and new CAs is also advisable. Though the company’s documentation and Servicing Stack updates are detailed and comprehensive, no system is immune to oversights, especially when trust boundaries underpin the entire executable verification process.
For organizations with security policies aligned closely to NIST, ISO, or industry-specific compliance frameworks, the default inferencing logic will generally align with best practices—but must be validated in context, especially where custom root-of-trust models are in play.
Practical Guidance for IT Administrators
Step 1: Review Supported Platforms and Update
Ensure that all managed systems have installed the relevant cumulative or servicing updates from May 2025 onwards, as outlined in Microsoft KBs. Devices left unpatched will lack the new trust logic and may experience issues as certificates expire and binaries are re-signed.Step 2: Audit Existing Application Control Policies
Identify policies—especially those with signer rules using TBS hash values for the soon-to-expire CAs. Confirm that these are present and explicitly trusted or denied, as per your current policy intent.Step 3: Validate Inferenced Policy Behavior
Use Microsoft’s policy auditing tools to verify that the inferenced logic triggers as expected, i.e., binaries signed by new 2023/2024 CAs are correctly trusted or denied according to the corresponding rules for old CAs.Step 4: Decide on Opt-Out Status
Evaluate whether your environment has specific compliance or operational requirements necessitating opt-out from the inferencing logic. If so, set the policy flag accordingly. Document your rationale for auditability.Step 5: Update Documentation and Incident Playbooks
Include the new CA mappings in your organization’s policy documentation and ensure your helpdesk, security, and operations staff are briefed on the changes, particularly in anticipation of phased certificate sunset events starting July 2025.Looking Forward: A Foundation for Long-Term Security
With threat actors continuing to exploit trust relationships and digital certificates, Microsoft’s proactive move to streamline the transition to new certificate authorities demonstrates a commitment to both usability and security. By blending intelligent automation with transparent opt-out controls, Application Control for Business strikes a thoughtful balance between operational simplicity and the granularity demanded by high-security enterprises.Still, this period represents a critical window for all organizations using Windows Application Control to review, audit, and refine their security policies, ensuring they not only avoid disruption as the CA infrastructure evolves, but also leverage contemporary best practices in application allowlisting and code authentication.
For most organizations, embracing the new inferencing logic promises to reduce migration headaches and head off threats posed by expiring certificates—a rare win-win in the sometimes frustrating world of enterprise security compliance. Nonetheless, success hinges on vigilance, timely updates, and open communication between IT administrators and Microsoft as the rollout continues.
References and Further Information
To verify specific technical details, TBS hashes, and update timelines, refer to the official Microsoft support documentation at Application Control for Business new CA handling logic. It’s also recommended to monitor the Microsoft Tech Community and Windows security blogs for the latest advisories and community-driven insights around the certificate transition process.In closing, as enterprises worldwide rely on consistent, predictable software security, the work done now to understand and implement these changes in Application Control for Business will pay dividends not just in continuity, but in resilience against an increasingly hostile threat landscape.
Source: Microsoft - Message Center Windows support for the Application Control for Business new CA handling logic - Microsoft Support