Security Requirements for Selecting SD-WAN: Criteria, Vendor Questions and Testing

An SD-WAN controller can push configuration and routes to every branch you own, so a flaw in the vendor's management or control plane becomes a flaw in your whole network at once. In February 2026 the US, UK, Australian, Canadian and New Zealand cyber agencies jointly warned that threat actors were targeting organisations' SD-WANs globally, exploiting a controller authentication bypass to add a rogue peer and gain persistent root access. That makes product security, not throughput, the first filter when you choose an SD-WAN. This vendor-neutral guide sets out the security requirements to write into an SD-WAN selection, whether the controllers are on-premises, cloud-hosted by the vendor or delivered as a managed service. It is for network architects, security reviewers and procurement leads. For hardening a fabric you already run, see the SD-WAN Security Guide.

Key takeaways

• The controller is the crown jewel. Judge each product on how its management, orchestration and control components are protected, patched and isolated, because compromise there reaches every edge.
• Vulnerability history is evidence. CISA added twelve vulnerabilities in SD-WAN management and orchestration products from three vendors to its Known Exploited Vulnerabilities catalog between January and September 2026; ask every bidder for its record and fix times.
• Device trust must be cryptographic and revocable. Require certificate-based onboarding of edges, controller allowlists, fast revocation and pairwise keys so that one stolen device or key cannot join or read the fabric.
• Logs must leave the platform. Remote syslog or streaming of control-plane, peering and admin events is mandatory; the joint advisory asked victims to preserve snapshots and logs before remediating.
• Decide the security boundary up front. Choose whether branch security lives on the SD-WAN edge, in a cloud SASE service or in separate firewalls before you compare products, or you will compare unlike things.

Define requirements

Start with the architecture and threats, then the commercial model. Write down:

• Deployment model: controllers you host, controllers hosted by the vendor as SaaS, or a carrier-managed service. Each moves patching and incident response to a different party, and you need to know which.
• Scale and topology: number of sites, hub-and-spoke or full mesh, cloud on-ramps, and data-centre or colocation hubs. Mesh topologies increase the number of tunnels and keys to manage.
• Security functions at the edge: stateful firewall, intrusion prevention, URL filtering, segmentation by VRF or segment, or none of these because traffic is sent to a SASE or SSE service. See the SASE and SSE Buyer's Guide.
• Cryptographic obligations: IPsec with IKEv2, FIPS 140-3 validated modules where you need them, and a dated plan for post-quantum key exchange. NIST SP 800-77 Rev. 1 is the US reference for IPsec VPNs.
• Administrative model: who administers the fabric (internal network team, managed service provider, carrier), how they authenticate, and whether configuration is managed through an API or infrastructure as code.
• Logging and response: where logs go, how long they are kept, and who can collect forensic images from controllers and edges during an incident.
• Regulatory and sector needs: critical infrastructure, government or financial sector rules on encryption, data location or supplier assurance.

Capability areas

Deployment models and their security trade-offs

Security requirements by area

The February 2026 joint advisory (NSA, CISA, ASD's ACSC, Canadian Centre for Cyber Security, NCSC-NZ and NCSC-UK) recommended placing controllers behind a firewall, isolating management interfaces, restricting manually provisioned edge addresses, replacing self-signed web certificates, keeping session timeouts short, using pairwise keying and forwarding logs to a remote syslog server. Each of these is a product capability you can test before you buy.

Evaluation criteria

Weights are an NHI Mgmt Group suggestion for an enterprise with many branches; raise the supplier assurance weight for managed services.

Check claimed cryptographic validations on the NIST Cryptographic Module Validation Program site. FIPS 140-2 validations remained acceptable until 21 September 2026, when CMVP said they would move to the Historical list, so a new deployment should rest on a FIPS 140-3 certificate. For the post-quantum transition see the Post-Quantum Cryptography Migration Guide.

Lessons from SD-WAN and edge incidents

The 2026 campaign showed the pattern. Attackers used a controller authentication bypass (CVE-2026-20127, added to the KEV catalog on 25 February 2026) to add a rogue peer, then escalated to root and stayed. Several further SD-WAN manager and orchestrator flaws from different vendors followed in the catalog during 2026. Broader telecom intrusions show the same reliance on network device credentials and secrets; see Salt Typhoon Telecom Intrusions 2025. The selection lessons:

• Peering must be authenticated and visible: you need an alert when any new device or controller joins the fabric, and a way to see every current peer.
• Controllers need edge-device patch speed: if you host them, budget to patch within days; if the vendor hosts them, require notification and fix commitments in the contract.
• Forensics must be possible: ask how you would snapshot a controller and collect logs before rebuilding it, and whether the vendor publishes hunting guidance during incidents.

See the Edge Device Security Guide for the wider edge device programme.

Where identity fits

An SD-WAN fabric runs on machine identities: device certificates and serial-number allowlists that decide which edges may join, control-plane certificates between controllers, IPsec keys between sites, and API tokens or service accounts used by automation and monitoring tools. Managed service providers add their own administrator identities across many customers. Require that device identities are certificate-based and revocable, that API credentials are scoped, expiring and attributable, and that every human administrator, including provider staff, signs in through your identity provider with MFA. See the Machine Identity, PKI and Certificate Lifecycle Guide and the Device and IoT Identity Guide.

Decision guidance

• Self-hosted versus vendor-hosted controllers: choose vendor-hosted when you cannot patch controllers within days and can accept a shared platform; choose self-hosted when regulation or sovereignty requires it and you can isolate and patch the controllers as tier-zero systems.
• Edge security versus SASE: keep firewalling on the SD-WAN edge for sites with local servers or OT that must not depend on a cloud service; send user internet traffic to SSE where you want one policy for branch and remote users. Compare against the Firewall Buyer's Guide.
• Managed service: attractive for small IT teams, but write log access, administrator identity, incident notification times and forensic cooperation into the contract.
• Small organisations: favour secure defaults, cloud-managed controllers and a short list of features you will actually configure.
• Large or regulated estates: require role separation between network and security teams, policy as code with review, FIPS 140-3 modules and a documented post-quantum plan.

Questions to ask vendors

• List every CVE in your SD-WAN controllers, managers, orchestrators and edges that appears in the CISA KEV catalog, with days from disclosure to a fixed release.
• Can controllers and the management interface be deployed with no internet exposure, and which ports must edges reach?
• How does a new edge prove its identity, how is it authorised to join, and how fast can we revoke a device or certificate across the fabric?
• Do edges use pairwise keys, how often are keys rotated, and which IKE and IPsec algorithms are supported and enabled by default?
• Which FIPS 140-3 certificate covers the cryptographic module on edges and controllers, and when will hybrid post-quantum key exchange be available?
• Can we replace every self-signed certificate with certificates from our own CA?
• Which events (admin login, policy push, new peer, control connection loss) are logged, and can they be streamed to our SIEM in real time?
• How would we collect forensic snapshots of controllers during an incident, and what hunting guidance did you publish in your last security incident?
• Which of your staff or provider staff can access our tenant, how is that access approved, and is it logged to us?
• Are firmware and software images signed and verified at boot, and can you provide an SBOM?
• What are the published end-of-support dates for the hardware and software trains you are proposing?

Red flags

• Controllers or management interfaces that must be internet-facing with no option to restrict source addresses.
• A pattern of repeated KEV entries with slow fixes, or security advisories available only behind a support login.
• Edges that can join with a shared secret or serial number alone, with no certificate and no revocation process.
• Self-signed certificates that cannot be replaced.
• Logs that exist only in the vendor console, or extra charges for exporting security logs.
• Default or hidden administrative accounts, or support access you cannot see.
• FIPS claims based on a FIPS 140-2 certificate or "designed to meet" wording with no certificate number.

Proof of concept

Run the proof of concept in a lab or a small group of non-critical sites, with existing WAN links kept in place for rollback.

1. Deploy controllers in the model you intend to buy and confirm management interfaces are reachable only from your management network. Port-scan the transport interfaces of edges and controllers.
2. Configure SSO and MFA for administrators and confirm local accounts are disabled or vaulted. Test role separation by attempting a policy push from a read-only role.
3. Onboard an edge through zero-touch provisioning, then try to onboard a device that is not on the allowlist and confirm it is rejected and logged.
4. Revoke an edge certificate and measure how long until the device loses all tunnels.
5. Inspect tunnel parameters and confirm IKEv2, the agreed algorithms and pairwise keys. See the IPsec Security Guide.
6. Stream logs to your SIEM and confirm admin logins, policy pushes and new peer events arrive within minutes. See the Network Device Syslog and Configuration Change Detection Guide.
7. Test segment isolation by attempting traffic between segments with no policy.
8. Upgrade the controllers and an edge during the test and measure outage, then roll back.
9. Agree go-live metrics: days to patch KEV-listed vulnerabilities, percentage of edges with certificate-based identity, unknown peer alerts investigated, admin accounts without MFA, and log delivery delay.

Primary sources used here: ASD's ACSC and partners: Exploitation of Cisco SD-WAN appliances, CISA: Known Exploited Vulnerabilities Catalog, CISA: Secure by Demand Guide, NIST: SP 800-77 Rev. 1 Guide to IPsec VPNs, NIST: SP 800-215 Guide to a Secure Enterprise Network Landscape, NIST: SP 800-53 Rev. 5, NIST: Cryptographic Module Validation Program and Mplify (formerly MEF): SD-WAN service standards, MEF 70.2 and MEF 88. A product is named only where a published advisory names it; 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: SD-WAN Security Guide · SASE and SSE Guide · ZTNA Buyer's Guide · Edge Device End of Life Replacement Playbook · Security Requirements for Selecting a Network Monitoring Tool