Security Requirements for Selecting a Load Balancer: Criteria, Vendor Questions and Testing

Load balancers and application delivery controllers terminate TLS, hold private keys and session state, and sit on the internet edge, which is why they keep appearing in the CISA Known Exploited Vulnerabilities catalogue. The product you choose sets your patch burden, the cryptography you can offer, how much of the request you can trust downstream, and whether you can investigate when something goes wrong. This vendor-neutral guide sets out the security requirements to write into a load balancer or ADC selection, whether you are buying hardware, a virtual appliance, a cloud-managed service or a software proxy. It is for network and platform architects, security reviewers and procurement leads. It covers selection only; for configuring a load balancer you already run, see the Load Balancer Security Guide.

Key takeaways

• Vulnerability history is a selection criterion. Check the product family against the CISA KEV catalogue and ask how fast fixes shipped; an appliance you cannot patch within days is a standing risk on the edge.
• The management plane must never face the internet. Require a dedicated management interface or API with SSO, MFA, role-based access and full audit logging, and treat any exposed admin service as a red flag.
• TLS policy control decides your crypto agility. Ask for named, versioned TLS policies, TLS 1.3, FIPS 140-3 validated modules where you need them, and hybrid post-quantum key exchange on the roadmap or available now.
• Session handling is an identity control. Session tokens and persistence cookies that survive patching or reboots let attackers keep access, so require session invalidation and secure cookie options.
• You need logs and forensic data off the box. Request logs, configuration change logs and integrity checks must stream to your SIEM, because local logs on a compromised appliance cannot be trusted.

Define requirements

Start from the traffic and the threat, then the form factor. Write down:

• Layer and protocol: layer 4 (TCP, UDP) pass-through, layer 7 HTTP and HTTP/2 or HTTP/3 termination, gRPC, or a mix. Pass-through keeps keys on the servers; termination lets you inspect and route but makes the balancer hold the keys.
• Exposure: internet-facing, internal east-west, or both. Internet-facing roles inherit the edge device threat profile: exploitation of public-facing applications (ATT&CK T1190) and theft of web session cookies (T1539).
• Cryptographic obligations: TLS versions you must offer, whether FIPS 140-3 validated modules are mandatory, and when you need post-quantum key exchange. NIST SP 800-52 Rev. 2 requires government TLS servers to support TLS 1.2 with approved cipher suites and TLS 1.3 from 1 January 2024.
• Backend trust: whether traffic to the servers must be re-encrypted and whether the balancer must present a client certificate (mutual TLS) to back ends or verify client certificates from callers.
• Bundled functions: WAF, bot management, remote access gateway or global server load balancing. Each extra module adds attack surface and its own patch stream; buy it only if you will operate it. See the WAF and WAAP Buyer's Guide.
• Operating model: who administers it, whether configuration is managed as code, and your target time to patch an internet-facing critical vulnerability.

Capability areas

Form factors and their security trade-offs

Defaults matter more than features. AWS documents that its Application Load Balancer console defaults to the ELBSecurityPolicy-TLS13-1-2-Res-PQ-2025-09 policy, while the CLI, CloudFormation and CDK default to the much older ELBSecurityPolicy-2016-08. Ask every bidder which policy each provisioning path applies by default, because most production estates are built by code, not by console.

Security requirements by area

RFC 7239 is clear that the Forwarded header cannot be relied upon to be correct, because any node on the path, including the client, can modify it. Your load balancer must therefore be able to strip or overwrite client-supplied forwarding headers, and your applications must only trust values added by it. RFC 7239 also warns against copying the header into responses, where it can reveal the internal proxy chain.

Evaluation criteria

Weights are an NHI Mgmt Group suggestion for an internet-facing deployment; reduce the vulnerability and session weights for internal-only use.

Check the CMVP status of any claimed validation. NIST's Cryptographic Module Validation Program validates modules to FIPS 140-3 and stated that FIPS 140-2 validations remained acceptable until 21 September 2026, when CMVP said they would move to the Historical list. A bid that relies on a FIPS 140-2 certificate for a new deployment should be challenged. For the wider migration, see the Post-Quantum Cryptography Migration Guide.

Lessons from edge appliance incidents

CitrixBleed (CVE-2023-4966) and CitrixBleed 2 (CVE-2025-5777) in NetScaler ADC and Gateway were both added to the CISA KEV catalogue with known ransomware use. Both leaked memory that included session tokens, so attackers could reuse authenticated sessions and bypass MFA; patching alone did not remove sessions already stolen. See CitrixBleed 2023 and CitrixBleed 2 (CVE-2025-5777). F5 BIG-IP CVE-2022-1388, a missing authentication flaw in the management interface, is also in KEV with known ransomware use. The selection lessons are concrete:

• Exposed features add risk: remote access gateway and management services on the same appliance as load balancing widen the attack surface. Turn off what you do not buy.
• Session kill is a requirement: you need a documented way to invalidate every active and persistent session after an incident.
• Vendor incident guidance matters: ask how the vendor publishes indicators of compromise and integrity checking tools, and how fast.

For hardening the two product families above, see the NetScaler ADC and Gateway Hardening Guide and the F5 BIG-IP Hardening Guide.

Where identity fits

A load balancer holds machine identities on both sides: the server certificates and keys it presents to clients, client certificates it presents to back ends, and the API tokens or service accounts that automation uses to change it. In cloud services, the IAM roles allowed to modify listeners and TLS policies are as powerful as appliance root access. Require that every automation credential is scoped, attributable and rotatable, and that certificates are inventoried and renewed automatically. See the Machine Identity, PKI and Certificate Lifecycle Guide and the API Key Management Guide.

Decision guidance

• Cloud-managed versus appliance: if your workloads already run in one cloud, a managed load balancer removes the appliance patching burden that drove most recent edge incidents. Choose an appliance or virtual ADC only when you need features the managed service lacks, such as advanced traffic scripting, specific HSM integration or on-premises placement, and budget for patching within days.
• Termination versus pass-through: terminate TLS at the balancer when you need layer 7 routing, WAF inspection or central certificate management. Use layer 4 pass-through when keys must stay on the servers or end-to-end encryption is mandated, accepting that you lose request-level logging at the balancer.
• Small organisations: prefer the option with secure defaults and no separate management plane to protect. One well-configured managed service beats an under-patched appliance.
• Large or regulated estates: expect to standardise TLS policies across many listeners, enforce them with policy as code, require FIPS 140-3 validated modules, and separate network, security and application administrator roles on the platform.
• Bundled remote access: avoid running a remote access gateway on the same appliance as production load balancing unless you can patch and monitor both at edge-device speed.

Questions to ask vendors

• List every CVE in this product family over the last three years that appears in the CISA KEV catalogue, and the days from disclosure to a fixed release for each.
• Can the management interface be bound only to a dedicated network or private endpoint, and is any administrative service reachable on data-plane interfaces by default?
• Which authentication methods protect the admin GUI, shell and API, can MFA be enforced for all of them, and are there any built-in or default accounts?
• Which TLS policy does each provisioning method (console, API, infrastructure as code) apply by default, and how are policies versioned and retired?
• Which FIPS 140-3 certificate covers the module used for TLS, and which hybrid post-quantum key exchange groups are supported today?
• Where are private keys stored, can they be marked non-exportable, and which HSM or KMS integrations are supported?
• How does the product handle conflicting Content-Length and Transfer-Encoding headers, and can it reject non-compliant HTTP requests?
• How can we invalidate every active session and persistence cookie at once after an incident?
• Which logs can be streamed off the device, and do you provide integrity checking tools and indicators of compromise during incidents?
• Can API tokens be scoped to specific objects and actions, set to expire, and listed with last use?
• What is the published end-of-support date for this model and software train?

Red flags

• A management interface exposed on the data plane by default, or default credentials that are not forced to change at first login.
• A pattern of repeated critical KEV entries with slow fixes, or advisories published only behind a support login.
• Insecure provisioning defaults through the API or templates, even if the console default is good.
• FIPS claims that rely on a FIPS 140-2 certificate or on "designed to meet" language with no certificate number.
• Forwarding headers passed through from clients unchanged, with no option to overwrite them.
• No way to terminate all sessions, or logs that exist only on the appliance.
• Hardware or software trains close to end of support with no migration path.

Proof of concept

Test in a staging environment that mirrors production, with the existing load balancer kept in place so you can roll back by switching DNS or routing.

1. Provision the load balancer through your normal infrastructure as code path and record the TLS policy and settings it receives by default. Compare with the console defaults.
2. Scan the listener from outside with a TLS scanner and confirm only the intended versions, cipher suites and key exchange groups are offered. See the TLS Server Configuration Baseline Guide.
3. Port-scan the data-plane addresses and confirm no administrative service answers. Confirm the admin GUI and API require SSO and MFA.
4. Send requests carrying forged X-Forwarded-For, Forwarded and Host values and confirm the back end sees only values set by the balancer. Send malformed and ambiguous HTTP requests and confirm they are rejected and logged.
5. Establish sessions, run the vendor's global session invalidation procedure, and confirm old cookies and tokens no longer work.
6. Make configuration changes with a scoped API token and confirm each change is logged with the actor and streamed to your SIEM. Revoke the token and confirm it fails.
7. Apply a software update in a high availability pair and measure traffic loss, then roll back.
8. Agree go-live metrics: days to patch KEV-listed vulnerabilities, percentage of listeners on the approved TLS policy, certificates expiring within 30 days, admin accounts without MFA, and log delivery delay.

After selection, run periodic reviews with the Load balancer and ADC health check.

Primary sources used here: CISA: Known Exploited Vulnerabilities Catalog, CISA: Secure by Demand Guide, NIST: SP 800-52 Rev. 2, NIST: SP 800-53 Rev. 5, NIST: Cryptographic Module Validation Program, IETF: RFC 7239 Forwarded HTTP Extension, AWS: Security policies for your Application Load Balancer and MITRE ATT&CK: Exploit Public-Facing Application. Products are named only to illustrate documented features or published vulnerabilities; this is not a recommendation.

How NHI Mgmt Group can help

We provide independent requirements, RFP and evaluation support. Browse vendors in our NHI and AI products directory or contact us.

Related NHI Mgmt Group resources: Load Balancer Security Guide · Edge Device Security Guide · Proxies and Forward vs Reverse Proxy Security Guide · Security Requirements for Selecting a CDN · DDoS Protection Buyer's Guide