You checked your CAs after the last post. You found defaults published. Now to replace them. Three steps, in order, with one setting that trips most people.
1. Create the replacement.
Duplicate the default. Set compatibility to the highest level your real consumers can use. Scope EKUs to what they actually need. Replace Authenticated Users with a specific security group. Make every change you wish the default had.
2. Supersede the old.
On the new template, Superseded Templates tab, add the original. Publish the new template on the CA. Autoenrollment will route new requests to the replacement, and existing certificate holders will renew onto the new template at their normal renewal cycle. The downloadable handout linked above shows the Superseded Templates tab on the new template, with the User default added.
3. Wait, or force the issue.
If you want faster than the natural renewal cycle, right-click the new template in certtmpl.msc and choose Reenroll All Certificate Holders. That bumps the template version and triggers re-enrollment on the next autoenrollment cycle. Use sparingly. Forcing re-enrollment across thousands of certificates is a self-inflicted DoS on your CA, especially with HSM-backed issuance. The handout shows where this lives in the right-click context menu.
Once you've verified the transition, unpublish the old template.
The setting that trips everyone: Compatibility.
A "Windows Server 2016" compatibility template doesn't mean older clients can't get a cert from it. The certificate is still X.509. An XP machine will happily receive one.
What the setting actually means: the template can use features that require modern client support. Key-based renewal. Specific CSP/KSP choices. If the client doesn't understand those features, it ignores them. The cert still works.
So pick the highest compatibility your oldest real consumer can use the features of. Not the oldest one that exists somewhere in your network.
One caveat that template replacement won't fix.
If you have systems that genuinely can't speak modern crypto protocols (SHA-1 only, weak TLS, ancient cipher suites), no template setting will save them. That's a different conversation. Segmentation. Replacement planning. Compensating controls. The new template will happily issue them a perfectly modern certificate they can't validate or use.
Most defaults can be replaced in an afternoon. The ones that can't usually have a story behind them. Knowing which is which is the actual work.
When was the last time you forced a re-enrollment, and what broke?
From the field
Years ago, did a forced re-enrollment on a User template at a client. About 12,000 user certificates. The HSM-backed CA was still issuing them 14 hours later. Got the after-hours call from the network team because we'd saturated the CA's NIC.
Now I tell people: if you have to bump the version, stage it with subsets of recipients (filter by OU, by site, by group, pick something that bounds the wave) so you don't do what I did.