Why we deprecated TLS 1.2 — and what that meant for one in nine of our customers

On December 15, 2025, SEND-SECURELY.COM dropped TLS 1.2 from our supported cipher suite list. Every connection to our platform now requires TLS 1.3. That decision was the right one; the process of getting there was the most operationally intensive deprecation we’ve run. About one in nine of our active customer workspaces had at least one integration that depended on TLS 1.2, and we broke all of them on purpose — after a 90-day communication campaign that we think got most of the important things right and a few things wrong.

This is an honest account of how we made the decision, what the runbook looked like, what broke anyway, and what we’d do differently.

The decision

The case for deprecating TLS 1.2 is not primarily about known exploitable vulnerabilities in TLS 1.2 itself — it’s about the protocol’s design constraints and the cipher suite flexibility those constraints allow. TLS 1.2 supports a broad set of cipher suites, including suites with weak key exchange, export-grade ciphers that have long been deprecated in practice, and algorithms we consider insufficiently forward-secure in the threat environment we’re operating in today. RFC 8996, which formally deprecated TLS 1.0 and TLS 1.1, was clear that TLS 1.2 would follow as TLS 1.3 adoption matured.

TLS 1.3, codified in RFC 8446, eliminates the cipher suite flexibility problem by removing the negotiation of weak algorithms entirely. There is no TLS 1.3 cipher suite with RSA key exchange, no static DH, no RC4, no DES. The handshake is faster, the forward secrecy is unconditional, and the attack surface from protocol downgrade and cipher suite negotiation is structurally reduced. For a platform whose entire value proposition depends on the integrity of file transfers, continuing to support TLS 1.2 purely for compatibility was an increasingly hard position to defend.

The internal debate wasn’t about whether to deprecate — that was directionally settled. It was about timing and approach. The questions we spent the most time on: how long a migration window to give customers, how to identify which customers were actually affected before the cutover date, and how to handle the integrations we couldn’t reach.

We also discussed whether to allow a TLS 1.2 exception for customers who documented a specific need. We decided not to. Exception frameworks for security deprecations tend to calcify: the exception becomes the new baseline, and the deprecation is never completed. We announced a hard cutover date and held to it.

The 90-day customer communication runbook

We started with measurement. Three months before announcing the deprecation, we began logging TLS version on every inbound connection. After two weeks of baseline collection, we had a clear picture: 11.3% of active workspaces had at least one connection source using TLS 1.2. That number — roughly one in nine — was higher than we expected, and it drove every subsequent decision about communication volume and support capacity.

Day 0: Announcement. We sent a deprecation notice to every workspace owner and technical administrator in our customer base. The notice stated the cutover date, explained the reason in plain terms, included a link to our migration guide, and flagged that customers with active TLS 1.2 connections would receive a follow-up notice specific to their workspace. Customers we hadn’t detected using TLS 1.2 got the announcement but no specific urgency messaging.

Days 1–14: Targeted outreach to affected workspaces. We identified every workspace with detected TLS 1.2 connections and sent a tailored notice that included: the specific integration sources we’d detected using TLS 1.2, the TLS version those sources were negotiating, and a suggestion to work backward from the source IP or hostname to identify the integration responsible. This sounds straightforward, but the IP-to-integration mapping was imprecise — many customers had automations behind NAT, and a single IP could represent dozens of integration endpoints. We erred toward over-notification: if we detected TLS 1.2 from an IP, we flagged the whole workspace.

Days 15–60: Biweekly reminders to affected workspaces still showing TLS 1.2 connections. We re-checked telemetry every two weeks and sent reminders only to workspaces still actively using TLS 1.2. As customers migrated their integrations, they dropped off the reminder list. By day 60 we had reduced the affected workspace count from 11.3% to 4.1%.

Days 61–80: Escalation to account contacts. For workspaces still using TLS 1.2 at the 60-day mark, we escalated communication to the named account owner — typically the person who signed the contract — rather than just the technical administrator. This was the most uncomfortable part of the runbook: reaching out to senior contacts about a technical issue felt like pulling an alarm. We did it because the 90-day timeline was firm and we needed to exhaust our communication options before cutover.

Days 81–89: Final warning and hard date restatement. One week out, we sent a final notice to all remaining affected workspaces — by this point, 2.3% of total workspaces — restating the cutover date in unambiguous terms: “On December 15, 2025, connections using TLS 1.2 will fail. There are no exceptions.”

Day 90: Cutover. We disabled TLS 1.2 at the load balancer level across all production endpoints. We had a war-room channel open for the 48 hours following cutover and scaled support capacity.

What broke

Despite the 90-day campaign, integrations broke on cutover day. The count was lower than we feared — approximately 0.4% of active workspaces had connections fail at cutover — but the pattern of what broke was instructive.

Legacy AS2 implementations. AS2 (Applicability Statement 2), the EDI-transport protocol used widely in healthcare clearinghouse workflows and retail supply chains, has an aging implementation tail. Many AS2 implementations are embedded in middleware, translation servers, or legacy ERP integrations that have not received active maintenance in years. The software negotiates TLS on behalf of the application, and the TLS version it supports is a function of the underlying library version — not something an operator can change without upgrading the software itself.

Several of our customers in healthcare supply chain and retail had AS2 integrations running on software whose TLS library predated TLS 1.3. These weren’t integrations anyone had thought about recently; they ran automatically and invisibly until they stopped working. One customer had an AS2 connection that had been running continuously for six years without a configuration change. It broke on December 15 and the operations team had no immediate path to upgrade the software.

Third-party MFT software with pinned TLS versions. Some legacy managed file transfer software allowed operators to configure which TLS version to use, and those configurations had been set to TLS 1.2 — not because TLS 1.3 wasn’t available, but because the configuration was set during original deployment and never revisited. These were fixable quickly once identified: changing a configuration value and restarting the service. But they required someone to know which configuration to change, and the connection failure was the first indication that a configuration existed that needed changing.

Older automation scripts. A smaller category but worth noting: customer-written automation scripts that called our API using HTTP client libraries with explicit TLS version constraints. A script written in 2019 using an older version of requests, curl, or a similar library might have hardcoded TLS 1.2 or defaulted to it. These were generally quick to fix once identified but required the customer to find and update scripts that had been running unattended for years.

The common characteristic across all breakages: these were integrations nobody was actively maintaining. They ran because they ran, and they failed because they failed. The 90-day communication campaign couldn’t fully reach the operational gap between “someone should check this” and “someone actually checks this.”

Lessons learned

Telemetry-first is the right approach. Starting with measurement before announcing the deprecation was the right call. It let us scope the problem accurately, target communication at the customers who actually needed it, and avoid the false urgency of mass-blast notices to customers who weren’t affected.

The AS2 tail is longer than it looks. AS2 exists in production environments that last received meaningful attention in the early 2010s. Any deprecation that touches TLS-layer concerns needs to explicitly consider AS2 in its scope and communication strategy. We knew AS2 was in our customer base; we underweighted how much of it was on unmaintained software. In future deprecations we’ll add AS2 connectivity to the affected-workspace analysis as a separate flag.

90 days is right but the escalation to account owners should come earlier. We escalated to account owners at day 61, and several told us they wished they’d heard earlier. If we run a similar deprecation, escalation to account contacts goes at day 45, not day 61. Senior stakeholders need time to find the owner of a legacy integration, schedule a maintenance window, and get software updated. Four weeks is a more realistic minimum than two.

Post-cutover support capacity was about right. We scaled our support team for the 48 hours after cutover, and the volume was manageable. The war-room channel format — dedicated channel with support engineers and infrastructure engineers both present — let us resolve the most complex breakages (the AS2 cases) quickly. We’ll keep this format for future deprecations.

For customers still running legacy integrations that depend on older TLS configurations: the same analysis applies to any connection point in your supply chain. The connections you’re not actively monitoring are the ones that will surprise you next time. Auditing TLS version telemetry on your inbound and outbound connections regularly is worthwhile maintenance, not just a response to a vendor deprecation notice.