H2C upgrade is the process of moving an HTTP/1.1 connection to HTTP/2 over cleartext using the Upgrade mechanism. It is intended for non-TLS connections, and when proxies forward the upgrade headers without enforcing policy, it can create a tunnel that bypasses normal content inspection.
What H2C Upgrade Means in HTTP
H2C upgrade is a protocol transition, not a new application feature. It begins as HTTP/1.1 and, through the Upgrade mechanism, negotiates HTTP/2 over cleartext on a non-TLS connection.
Because the exchange starts in plain HTTP, H2C only makes sense when both endpoints explicitly support it and the deployment has been designed to allow cleartext HTTP/2. That is why it appears in controlled environments, lab systems, or internal service paths rather than as a general-purpose internet default.
How the Upgrade Flow Works
The client sends an HTTP/1.1 request with upgrade headers that indicate a desire to switch protocols. If the server accepts, the connection changes to HTTP/2 framing without first establishing TLS. The visible behavior is a negotiated protocol change on the same underlying TCP connection.
This matters because the upgrade is opportunistic and policy-sensitive. If intermediaries understand and honor the transition, the connection can operate as intended. If they merely forward the headers, they may stop applying controls that were expected on the original HTTP/1.1 path.
Where H2C Fits in Network Architecture
H2C is primarily an interoperability and transport choice. It can reduce protocol overhead and preserve HTTP/2 semantics on networks where TLS is not used, but it also inherits the trust assumptions of cleartext HTTP. In practice, it depends on consistent handling by clients, servers, load balancers, and proxies.
That dependency makes the term relevant to gateway behavior, reverse proxies, service meshes, and edge enforcement points. A deployment can appear to be using standard HTTP controls while actually carrying upgraded traffic that follows a different parsing and framing model once the switch occurs.
Security Implications of H2C Upgrade
H2C is security-sensitive because the upgrade path can change how traffic is inspected and enforced. When a proxy forwards upgrade headers without policy enforcement, the resulting HTTP/2 tunnel may bypass expected content inspection or request-level controls.
It also means confidentiality is not provided by the transport itself. Any protection must come from network trust boundaries, segmentation, or higher-level application controls rather than from the protocol transition.
Risk and Threat Considerations
H2C upgrade can create a policy bypass when intermediaries treat the connection as ordinary HTTP/1.1 until the upgrade is complete, then lose visibility into the resulting HTTP/2 stream. That can weaken filtering, monitoring, and request validation in environments that assumed a proxy would remain in the path.
Failure mechanism: A proxy or gateway forwards Upgrade headers without blocking or revalidating the protocol change, allowing traffic to move into an HTTP/2 tunnel that is not inspected with the same controls as the original request path.
Impact: Security teams may miss malicious payloads, hidden routing behavior, or unauthorized use of internal services, especially when the cleartext channel crosses trust boundaries that were not designed for protocol switching.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-7 — Boundary Protection | H2C can bypass intermediary inspection and boundary enforcement. |
| AC-4 — Information Flow Enforcement | Upgrade handling affects whether traffic flows are still mediated by policy. | |
| Recommendation — Enforce SC-7 controls to stop unapproved protocol upgrades from crossing security boundaries. Apply AC-4 to preserve policy enforcement after protocol negotiation changes. | ||
| NIST CSF 2.0 | PR.DS-01 — Data-at-rest is protected | Cleartext H2C does not protect data in transit, so transport protection expectations must be explicit. |
| Recommendation — Use PR.DS-01 alongside transport controls to ensure sensitive data is not exposed on cleartext paths. | ||
| CIS Controls v8 | CIS-13 — Network Monitoring and Defense | H2C-related tunneling can reduce visibility unless network defense controls detect it. |
| Recommendation — Use CIS-13 to detect and inspect upgraded traffic paths that evade normal monitoring. | ||
| ISO/IEC 27001:2022 | A.8.20 — Network security | H2C affects how network traffic is routed, inspected, and controlled across components. |
| Recommendation — Implement A.8.20 to control protocol transitions and preserve inspection on network paths. | ||
Practitioner Guidance
Why practitioners should care: H2C is one of those protocol features that looks harmless in isolation but can materially change enforcement behavior in the middle of a request path. Treat it as an explicit architectural choice, not a passive default.
What to watch for: Review where Upgrade headers are allowed, where proxies terminate or forward them, and whether downstream components continue to inspect traffic after negotiation. If a cleartext upgrade is not required, disable it or constrain it to trusted internal paths.
Practitioner takeaway: The key question is not whether HTTP/2 is supported, but whether every hop in the path preserves the security policy you expect after the upgrade occurs.
Related resources from NHI Mgmt Group
- How should security teams decide when an enterprise password manager needs an upgrade?
- What should teams check before they plan a password manager upgrade?
- What breaks if organisations treat post-quantum migration as a one-time upgrade?
- How should teams test identity-sensitive flows after a Next.js upgrade?
