Qualys Adds HTTP/3 Across Its Shared Cloud Platforms

Qualys is giving its security platform traffic a new transport option, but the most important part of the rollout is how little it asks customers to change. In a customer advisory published on November 2, 2026, Qualys said it is introducing HTTP/3 across its Shared Cloud Platform (SCP) environments while keeping HTTP/1.1 and HTTP/2 available.

Qualys says the rollout began October 26 and is targeted to complete across its SCP platforms by November 3, with individual platform pods scheduled through late November. The advisory describes the change as additive: clients that can use HTTP/3 may negotiate it, while other clients continue over the TCP-based path they already use.

That makes this more than a protocol announcement. It is a small but practical infrastructure decision for organizations whose firewalls, proxies and egress policies treat UDP differently from TCP. The upgrade may improve connection behavior for supported clients, but the benefit depends on whether outbound UDP/443 is permitted to the relevant Qualys URLs.

What changes and what does not

HTTP/3 is the newest major version of HTTP and runs over QUIC. Unlike HTTP/1.1 and HTTP/2, which normally use TCP, HTTP/3 uses UDP as the transport for QUIC connections. Qualys says its platform will negotiate HTTP/3 with clients that support it and will leave existing HTTP/2 or HTTP/1.1 connectivity in place.

That means the rollout is not a forced migration from one protocol to another. The user interface, API, Scanner Appliance and Cloud Agent traffic should continue to work if an organization makes no firewall change. The trade-off is that a network allowing only TCP/443 will not receive the HTTP/3 performance benefit for those connections.

The distinction is useful for change planning. A protocol becomes operationally disruptive when an existing path disappears or when a new requirement is silently introduced. Qualys is describing the opposite model: add the new path, keep the old path, and let connection negotiation select what is available.

Why UDP/443 becomes the key network question

Many organizations allow outbound HTTPS over TCP/443 but restrict outbound UDP by default. That policy can be sensible for a tightly controlled environment, but it also means a client may never reach the HTTP/3 path even when the remote service supports it.

Qualys recommends confirming with the network or security team whether outbound UDP is blocked for HTTPS traffic. If an organization wants the new transport option, it can permit outbound UDP/443 to the relevant Qualys platform URLs alongside the existing TCP/443 rule. The advisory explicitly says not to remove or replace the TCP allowance.

For a security team, this is a narrow egress review rather than a broad “open UDP” request. The useful question is not whether UDP/443 should be allowed everywhere. It is whether the specific Qualys destinations, client groups and inspection paths can be handled under the organization’s existing outbound policy.

HTTP/3 also changes what to observe

A protocol fallback can hide a successful service connection while masking the absence of the new path. A user may see no outage at all, because the client falls back to HTTP/2. That is good for continuity, but it can make the rollout look invisible in ordinary application testing.

Teams that care about the performance or latency benefit should distinguish between “the Qualys connection works” and “the client negotiated HTTP/3.” Review egress logs, firewall decisions, proxy behavior and client telemetry where available. A TCP-only result confirms reachability, not use of QUIC.

It is also worth checking whether middleboxes inspect or reshape UDP traffic. A proxy, secure web gateway or network sensor may handle TCP and UDP differently. The right result is not simply a successful handshake; it is a stable path that remains visible to the organization’s monitoring and policy controls.

A concrete rollout checklist

1. Map the affected connections. List the Qualys UI, API, Cloud Agent, Scanner Appliance and integration traffic that leaves your network.
2. Confirm the platform pod. Qualys publishes a pod-by-pod schedule in the advisory, so use the schedule to determine when a given environment is expected to receive HTTP/3.
3. Check the egress rule. Verify whether outbound UDP/443 is blocked, allowed, or inspected for the relevant Qualys destinations. Keep TCP/443 available.
4. Test the fallback path. Before changing policy, confirm that existing TCP connectivity still works through the firewall, proxy and monitoring stack.
5. Enable narrowly if useful. If the organization wants HTTP/3, permit the required UDP path to the documented Qualys URLs rather than broadening UDP access generally.
6. Observe the result. Check connection logs and service telemetry after the pod’s rollout window. Look for negotiated protocol, blocked UDP attempts, retries or unexpected proxy behavior.

The security boundary remains TLS

Qualys notes that HTTP/3 runs over QUIC, which requires TLS 1.3; there is no non-encrypted HTTP/3 mode. The move to UDP therefore does not mean the platform is switching to an unprotected transport. It changes how packets are carried and how network controls must account for them.

The operational trade-off is that a new transport can complicate visibility for older network tooling. Some environments may prefer to keep the TCP fallback until their inspection and logging paths are ready. Others may permit UDP/443 but monitor it under a separate policy. Neither choice changes the fact that TCP/443 remains the continuity path in Qualys’s advisory.

What this rollout means for platform teams

Qualys’s announcement is a good example of a compatibility-first infrastructure update. The performance opportunity is real only for clients and networks that can use HTTP/3, but the migration pressure is low because the existing protocols remain available.

For most teams, the immediate task is not to redesign connectivity. It is to identify the relevant pod, confirm how UDP/443 is handled, preserve TCP/443, and decide whether measuring HTTP/3 is worth the additional network change. That turns a protocol rollout into a controlled, observable choice instead of a surprise firewall exception.

This article is a general information summary based on the cited public sources. It is not legal, cybersecurity, or compliance advice.