What should security teams do with TLS, S/MIME and SSH now?

What security teams should inventory first

The right starting point is to treat TLS, S/MIME and SSH as active trust infrastructure, not as background plumbing. Security teams should identify every place those protocols are used, then map the certificates, keys, trust stores and automated dependencies that keep them working. That inventory should include external-facing services, internal service-to-service traffic, email signing and encryption, admin access, bastions and any embedded or hard-to-rotate credentials.

For TLS, the critical question is where expiry or policy change would create user-visible outages or break service chains. For S/MIME, the focus is on mail continuity, mailbox migration and whether long-lived signing or encryption keys remain recoverable. For SSH, the most important issue is orphaned keys, shared accounts and unmanaged SSH key and SSH certificate management, because those are the places where last-minute replacement becomes both slow and risky.

How to decide what needs early migration

Not every use of these protocols needs to move at the same pace. Early migration is most justified where the trust value is high, the retention period is long, the protocol is hard to replace without coordination, or the failure blast radius is broad. Examples include customer-facing TLS, certificate chains embedded in appliances, archival S/MIME mail, administrative SSH access used across many systems, and any workflow where manual certificate or key replacement would require a change window across multiple teams.

Security teams should distinguish between routine renewals and structural migration work. Routine renewals can often be handled by existing automation and playbooks. Structural migration is needed when the current protocol use depends on brittle trust assumptions, such as long-lived private keys, unmanaged certificate authorities, undocumented host key pinning, or SSH access paths that survive far longer than the systems they protect. The goal is to reduce future coupling before a forced replacement creates operational pressure.

Where certificate lifecycle management is already mature, teams can use the transition to improve renewal automation, key protection and crypto agility at the same time. Where lifecycle management is weak, migration planning should start with the most fragile estates first, especially anything with embedded certificates, slow change control or dependencies that are expensive to reissue. A practical reference point for certificate lifecycle issues is Machine Identity, PKI and Certificate Lifecycle Guide.

What good looks like during the transition

A good transition plan has three visible traits: ownership, time bounds and fallback paths. Every protocol estate should have a named owner, a refresh or retirement date, and a documented plan for what happens if a certificate, key or trust anchor fails sooner than expected. Teams should know which systems can be rotated automatically, which need manual coordination and which require business sign-off because the protocol is tied to a regulated or high-trust workflow.

For TLS, good practice is to reduce dependency on manually renewed long-lived certificates and to remove hidden trust anchors before they fail. For S/MIME, it means validating that users can still decrypt needed mail after certificate changes and that signing continuity is preserved. For SSH, it means eliminating shared keys, removing stale authorized_keys entries and preferring certificate-based or centrally governed access where operationally feasible. The safest programs are the ones that can prove they know where every trust relationship lives before the deadline arrives.

When certificate issuance and revocation matter for publicly trusted TLS, the baseline rules from CA/Browser Forum are a useful external reference point for what modern public trust expects from issuance and lifecycle discipline.

Practitioner Guidance

What to prioritise: Start with the services that would cause an outage, compliance issue or access loss if a certificate or key expired unexpectedly. If a protocol instance protects many downstream systems, it belongs near the front of the migration queue.

What to verify: Confirm which renewal paths are automated, which are manual and which are effectively tribal knowledge. Pay special attention to exported private keys, undocumented SSH trust and S/MIME archives that cannot be reissued without user impact.

Common mistake: Treating all TLS, S/MIME and SSH deployments as if they have the same urgency. In practice, the migration order should be driven by trust value, retention horizon and operational fragility, not by the protocol name alone.

Practitioner takeaway: The best teams do not wait for protocol replacement to become urgent, they isolate the brittle dependencies early so migration happens on their schedule, not during an outage or emergency change window.

Related resources from NHI Mgmt Group

• How should security teams audit SSH passwordless access at scale?
• How should security teams govern SSH port forwarding in privileged access workflows?
• How can security teams tell whether onboarding access is over-scoped?
• How can security teams tell whether API audit logging is actually useful?