It took me awhile to dig up evidence for this, but the closest I can find is that subordinate CA certificates will no longer be allowed to have id-kp-clientAuth EKU [1], however this restriction does not apply to leaf certificates.
It applies to leaf certs too. (Full disclosure - I work in the industry, so know this well).
After June 15th, 2026 - no leaf certs with serverAuth and clientAuth.
Mind you, client authentication with public certificates is a bad idea anyway, but I appreciate many people do and it's just been 'the way' for many years.
This is why I think it's going to hurt if folks don't realise soon and start to plan.
I cannot find any hard evidence of this claim -- I don't have reason to believe you're making it up, but I also would expect this change to be more widely announced. The best I can find is some discussion by Let's Encrypt staff that the roots want to stop issuing clientAuth-enabled leaf certificates eventually. However, there haven't been any hard timelines established because (at least) some mail servers in particular are using ___domain-validated public certificates for opportunistic mTLS.
I've scoured the CA/Browser Forum BRs and ballots, Chrome Root Store policies, and CCADB policies, and can't find mention of this coming restriction.
Wow, I completely missed bullet 2. It's quite clear:
All corresponding unexpired and unrevoked subscriber (i.e., TLS server authentication) certificates issued on or after June 15, 2026 MUST include the extendedKeyUsage extension and only assert an extendedKeyUsage purpose of id-kp-serverAuth.
[1]: https://googlechrome.github.io/chromerootprogram/#321-applic...