Field note
TLS Inspection: Deploy Client Certificate Trust
Creating a managed certificate is quick. Establishing the right trust on every affected client is the deployment.
A browser certificate warning after a security change is a deployment failure to investigate. Users should not be taught to click through it.
Microsoft’s 12 October Entra roundup includes preview Microsoft-managed certificates for TLS inspection.
The feature removes the need to supply your own inspection certificate authority, but the client trust and application compatibility work remains.
Decide what will be inspected
Microsoft’s TLS inspection overview describes HTTPS being decrypted at the service edge, evaluated by configured controls and re-encrypted towards the destination. Make that processing boundary part of the design discussion with the organisation’s security and privacy owners.
Choose a small set of appropriate test destinations and an approved test population. Agree which traffic should be inspected and which should be excluded before activating the policy. Do not start with every destination merely because a broad rule is easier to create.
The existing web content filtering article deals with a related control, but category blocking and decrypting traffic are different deployment decisions. Explain the additional inspection behaviour clearly in the user notice and support instructions.
Distribute trust before enabling the policy
The managed-certificate guide says Microsoft creates a tenant-specific root CA and keeps the private key within its infrastructure. Administrators download the public root certificate, distribute it to clients and then enable the managed certificate.
Retain a configuration record with the certificate’s identity, expected thumbprint, validity and deployment scope. The record should let another administrator distinguish the intended root from a similarly named older certificate.
For Intune-managed endpoints, follow the trusted-root profile documentation. Use the correct profile and platform, then verify the resulting certificate on representative devices. A profile assignment is evidence of intent; the local trust store is evidence that the device received it.
Include existing devices, a newly enrolled device and one that has been offline. The last case matters because certificate deployment and policy delivery can arrive at different times. Do not assume all assigned endpoints are ready on the day the profile is created.
Test trust and application behaviour separately
First confirm that an approved inspected destination presents the expected certificate chain without a warning. Then perform the business task in the application. A page loading successfully does not prove that uploads, background connections or embedded authentication all work.
Microsoft’s inspection FAQ explains that certificate-pinned applications can fail under interception and may need a narrowly defined bypass. It also documents protocol limitations, including Encrypted Client Hello. Check the current guidance against the applications in the pilot.
Keep a short test record:
| Result | What to investigate |
|---|---|
| Certificate warning | Root deployment, chain and policy scope |
| Browser works but application fails | Application trust behaviour and pinning |
| Some destinations bypass inspection | Effective rules and documented system exclusions |
| Access fails after a certificate change | Which root and active certificate the client actually uses |
Avoid bypassing a whole category of useful traffic because one application fails. Identify the exact destination or application requirement and record the owner, reason and review date of the exception.
Rehearse the certificate transition
A managed certificate still has a lifecycle. Microsoft documents creating and deploying the replacement root before enabling the new certificate, validating it, and only then removing the old disabled certificate. Follow that ordering.
For a pilot, write down how to return the affected group to its previous inspection assignment. Keep the earlier certificate and trust configuration available for the agreed validation period. Removing trusted roots too early can turn a contained rollback into a second outage.
Do not interpret successful certificate rotation as a test of every security rule. After the trust transition, verify the specific content controls the organisation intended to apply and record their separate results.
Assign someone to monitor certificate expiry, failed deployments and bypass growth. Review the operating-system and application mix before each wider rollout stage; a pilot consisting only of current Windows laptops may miss a material part of the estate.
The rollout is complete when the intended clients trust the intended certificate, approved traffic is handled as designed, incompatible applications have justified exceptions and support can reverse a failed change. Microsoft managing the certificate authority is useful, but those acceptance decisions still belong to the organisation.
References
- Microsoft — October Entra announcement, 12 October 2026. Accessed 17 October 2026.
- Microsoft — Configure TLS inspection with a Microsoft-managed certificate. Accessed 17 October 2026.
- Microsoft — How TLS inspection works. Accessed 17 October 2026.
- Microsoft — TLS inspection frequently asked questions. Accessed 17 October 2026.
- Microsoft — Trusted root certificate profiles in Intune. Accessed 17 October 2026.
Related notes
17 Oct 2026 · 4 min
16 Mar 2026 · 4 min
17 Oct 2026 · 4 min
Need help mapping this to your own tenant, controls, or assessment timeline?