You turned on TLS 1.3, the scanner still reports TLS 1.0, and it looks like the change did not take.
It did. Enabling a protocol version and disabling one are separate actions. Your server advertises a list of versions it will accept, and the client picks from that list. Adding TLS 1.3 to the list does not remove TLS 1.0 from it, and an attacker attempting a downgrade gets to choose from exactly the same list your visitors do.
Test each version individually
Asking a server what it supports is less reliable than trying each one:
for v in tls1 tls1_1 tls1_2 tls1_3; do
printf "%-8s " "$v"
openssl s_client -"$v" -connect example.com:443 -servername example.com </dev/null >/dev/null 2>&1 \
&& echo "ACCEPTED" || echo "refused"
doneAnything reporting ACCEPTED for tls1 or tls1_1 is still reachable, whatever your configuration file says it does.
Note that a recent OpenSSL build may refuse to offer TLS 1.0 at all, in which case you get a false “refused”. If the result disagrees with what a scan reports, trust the scan.
Where the setting actually lives
| If TLS terminates at | Change it here |
|---|---|
| A CDN or edge provider | Their dashboard’s minimum TLS version setting. Your origin configuration is not what visitors negotiate |
| A load balancer | The listener’s security policy, which is usually a named preset rather than a version list |
| Nginx | ssl_protocols, and check every server block rather than the first one you find |
| Apache | SSLProtocol, same caveat about virtual hosts |
| A managed platform | Often a single toggle, sometimes not exposed at all |
The most common reason a change appears to do nothing is that it was made one layer behind whatever actually faces the internet.
Find the clients before you break them
The reason TLS 1.0 is still enabled is usually that somebody, once, could not connect without it. Work out who that was before removing it.
Server logs that record the negotiated protocol version are the quickest route. A week of data will tell you whether anything real is still using the old versions, and in most cases the answer is nothing at all. The exceptions cluster in predictable places: payment terminals, embedded and industrial devices, and old Java or .NET integrations run by a partner who will not find out until it breaks.
Removing TLS 1.0 during business hours with no idea who uses it is how a quiet compliance task becomes an incident.
Confirm across every address
Re-run the loop above after the change, then repeat it against each individual address the hostname resolves to, including IPv6. A version policy applied to one node in a pool leaves the others exactly as they were.
More detail in TLS versions and deprecated protocols. Removing old versions also changes which cipher suites and key exchanges are in play, so it is worth reading weak and legacy cipher suites and forward secrecy alongside it.