Supabase plans to remove four older CBC-mode TLS 1.2 cipher suites from project HTTP APIs starting November 10, 2026 at the earliest. TLS 1.3 is unchanged. The useful preparation is to identify the devices and integrations that actually connect to your project, especially older clients that cannot negotiate another supported connection.
The notice was published October 12, and this guide checks it against Supabase's troubleshooting documentation on October 16. It uses a hypothetical US field-service product to show how to organize a compatibility review. It does not claim that a specific customer, device fleet or Supabase project is affected.
Key takeaways
- The change removes selected TLS 1.2 ciphers, not TLS 1.2 as a whole.
- Project HTTP API connections and direct database connections have different scope.
- Test the actual old client and its network path; a successful connection from a modern developer laptop answers a narrower question.
Understand the scope and timing
Supabase's notice names the four ECDHE ECDSA/RSA AES-128/256 CBC suites ending in SHA256 or SHA384. It applies to project supabase.co hosts and custom domains. Auth, the Data API, Storage, Realtime and Edge Functions share the affected HTTP API surface. Direct Postgres, pooler and Management API connections are excluded.
The stated removal date is November 10 at the earliest, rather than a promise of an exact cutover time for every project. Supabase says owners whose projects received connections using these ciphers are being contacted. Use any project-specific notice as part of your inventory and prepare before the earliest date. Avoid describing this as a general Supabase outage or assuming every older device will fail.
Supabase: October 12 CBC cipher deprecation notice and timeline
Inventory callers, not just the main app
A fictional field-service company uses a web dashboard, an iPad app, an unattended Windows import job and an older embedded measurement device. All may belong to the same product, but each can use a different operating system, runtime, TLS library and network route. The dashboard working does not establish that the importer or device is compatible.
For every caller, record the destination host, API path, application version, runtime, operating system, connection library, owner and update method. Include a custom-domain proxy or corporate inspection gateway where one exists. Find out which component makes the final connection to Supabase; that is the client whose supported negotiation matters at that boundary.
| Caller | Connection to review | Required evidence |
|---|---|---|
| Current dashboard browser | Project HTTP API through its real network path | Supported negotiated connection on the agreed browser set |
| Installed mobile application | App's shipped OS and networking stack | Tests on the oldest supported OS and app version |
| Unattended Windows importer | Scheduled job's actual runtime and service identity | A connection test from the job environment |
| Embedded measurement device | Firmware TLS capabilities and any gateway | Vendor support details plus representative-device test |
| Database administration client | Direct Postgres or pooler, if that is its actual path | Path classification; the notice excludes those connections |
Separate a TLS failure from an API rejection
Supabase's troubleshooting page explains that this class of failure happens during the TLS handshake, before the HTTP request reaches the API. It may therefore leave no request in project API logs. The same page lists examples such as ERR_SSL_VERSION_OR_CIPHER_MISMATCH and Java SSLHandshakeException, but an error label alone does not identify the underlying cause.
Collect the failing client's runtime and network details, destination and a timestamp, then compare with a supported client on the intended path. Confirm the negotiated protocol and cipher using tooling appropriate to that runtime. A diagnosis should explain which connection failed, not just show that a server is reachable.
On October 16, the announced removal has not yet reached its earliest date. Supabase explicitly says handshake errors before removal are not caused by this upcoming change. Investigate the current failure rather than attaching the newest announcement to every SSL error.
Which clients still need a compatibility check?
Bring the mobile versions, scheduled integrations and device constraints. We can help review the connection paths and plan the required updates.
Verify a supported connection from the real environment
Organize the review around evidence you can reproduce. Use an approved test account and a non-destructive request appropriate to each service. Record the protocol and cipher negotiated by the actual supported client, the application result and the environment used. A successful test today that negotiates a cipher due for removal does not prove future compatibility.
Where a client can negotiate a supported alternative, verify that behavior in a controlled test. Where its capabilities are unclear, obtain the operating-system or device vendor's support details and have the responsible engineer test the specific stack. Do not force a global TLS setting across all product clients simply because one legacy caller needs investigation.
Include the path customers use in practice. A scheduled process can run under a different runtime or configuration from an interactive terminal. A mobile device can pass on office Wi-Fi and behave differently through a managed network gateway. Keep the evidence scoped to what was observed, and record missing environments as unresolved.
- Identify the precise caller, destination and network intermediary.
- Record a supported negotiated connection and the expected application response.
- Test the oldest version the product still promises to support.
- Assign an owner and completion date to every unknown or incompatible client.
Plan remediation without losing field work
For a client that cannot make a supported connection, plan an operating-system, runtime, library or firmware update with its owner. If the device cannot be updated, involve the vendor and evaluate the alternatives before the deadline. Keep the change small enough that connectivity and business behavior can be verified together.
Supabase describes a controlled proxy as a possible fallback for clients that cannot be updated. That creates another service to operate and an additional transport boundary to review. If evaluating it, specify authentication, allowed destinations, monitoring and ownership; do not introduce an open relay or silently broaden what the old client can access.
In the fictional field-service app, the device may collect measurements while disconnected. Check how unsent work is retained, how the user sees its state and how the office confirms receipt after recovery. A connection fix is incomplete if a retry duplicates a completed measurement or loses the local record.
Define local saves and confirmed delivery in an offline field app
Keep database authorization checks separate from transport compatibility
Prepare a support note the whole team can use
Before the earliest cutover, summarize which clients were verified, which were updated and which remain outside the product's support policy. Give support a way to identify the affected app or device version without asking a customer for passwords, API keys or complete sensitive logs. Keep the precise compatibility evidence in the engineering record.
After the provider change, watch service completion and caller failures alongside API metrics. An absence of HTTP errors cannot exclude a handshake failure that never reached HTTP. If a problem appears, compare it with the previously tested environment and use Supabase support when project-specific clarification is needed.
The result should be a clear compatibility decision for each supported caller and a recovery path for unsent work. MUBBITS can help review the integrations and client versions that connect an existing web or mobile product to its backend.
Frequently asked questions
Is Supabase disabling TLS 1.2 entirely?
No. The notice removes four specified CBC-mode TLS 1.2 cipher suites. It states that TLS 1.3 is unchanged; clients using another supported connection are a separate compatibility case.
Are direct Postgres and pooler connections included?
The notice excludes direct Postgres, pooler and Management API connections. Confirm the caller's actual destination before applying that exclusion to your integration.
Can an empty API error log prove my old client is working?
No. A TLS handshake can fail before an HTTP request reaches the API. Test the actual client connection and the application outcome as well as reviewing server-side logs.
Let’s work through your next step.
Tell us what you’re building, what you’ve tried, and where you need a hand. We’ll work with you to define a practical way forward.