A credit-union auditor reports that outdated TLS 1.0 clients can still negotiate to the municipal dispute portal hosted on App Service. Which App Service setting should the developer raise to block those clients?

The auditor found that outdated TLS 1.0 clients can still negotiate to the municipal dispute portal. App Service exposes Minimum TLS version as a TLS policy control on the web app (or plan-level TLS settings, depending on UI). Raising that floor to TLS 1.2 or higher rejects handshakes that only offer older protocols, which is exactly what compliance reviews expect for public municipal portals. The setting applies at the platform edge before application code runs, so every site hostname on that app inherits the stronger floor once it is saved.

Always On keeps the site loaded so idle workers are less likely to unload; it improves responsiveness after idle periods but does not filter cipher or protocol negotiation. ARR affinity pins a client to one instance with an affinity cookie, which helps sticky in-memory sessions across scale-out, yet it has no role in blocking TLS 1.0. Remote debugging attaches a debugger to the worker process for development troubleshooting; leaving it enabled in production is a security smell and still does not enforce a minimum TLS version.

Exam caveat: Minimum TLS version and HTTPS-only are complementary but distinct—HTTPS-only forces scheme redirect, while Minimum TLS version decides which protocol versions are accepted after TLS begins. Operational check: after raising the floor, attempt a controlled TLS 1.0-only client connection (or use a TLS testing tool against the portal hostname) and confirm the handshake is refused, while a modern TLS 1.2+ client still succeeds.