Cisco SD-WAN Manager Hardening Guide: Admin Access, Peering and Patching

Cisco Catalyst SD-WAN Manager (formerly vManage) pushes configuration and policy to every branch in the fabric, so an attacker who controls it, or who can impersonate a peer to it, controls the WAN. In 2026 Cisco disclosed a CVSS 10.0 peering authentication bypass in the Controller, Manager and Validator (CVE-2026-20127) and a set of Manager API flaws, several exploited, and CISA tied its Known Exploited Vulnerabilities entries to Emergency Directive 26-03. This guide is the Manager-specific hardening and response reference: management plane exposure and ports, roles and authentication, system accounts and API credentials, logs and indicators, a hardening baseline and when to rebuild. It is for network security engineers and SD-WAN operators. Architecture and the wider fabric are in the SD-WAN Security Guide, which this page does not repeat. Settings, ports and advisory details were checked against Cisco's hardening guide and advisories on 27 October 2026; advisories are updated, so confirm fixed releases on the current version.

Key takeaways

• Manager ports are not internet services. Cisco's hardening guide limits TCP 22 and 443 to a jump host or management subnet and NETCONF (TCP 830) to the Manager talking to Controllers and Validators.
• There were no workarounds. Cisco stated no workarounds fix CVE-2026-20127 or the Manager API flaws in cisco-sa-sdwan-authbp-qwCX8D4v; restricting ports 22 and 830 is a temporary mitigation and upgrading is the fix.
• Watch the system accounts. Cisco's indicator guidance centres on vmanage-admin public key logins in /var/log/auth.log from addresses that are not your controllers, and on unexpected control connection peers.
• Least privilege uses custom roles. Built-in roles are basic, operator, netadmin, network_operations and security_operations; netadmin is full control and should be rare.
• Upgrading does not remove a compromise. Cisco's remediation note says the upgrade protects against future exploitation but not an existing compromise, which is why indicator checks and, where needed, a fabric rebuild come first.

How identity and access work in SD-WAN Manager

SD-WAN Manager authenticates three kinds of identity, and the 2026 vulnerabilities touched all three.

The internal accounts are non-human identities with real privilege. They are rarely reviewed because they are created by the product, yet they are exactly what Cisco's indicator guidance asks you to check. See the Non-Human Identity (NHI) Guide.

Admin roles and privileged access

• Scope users: each user has a role and a scope (sites, devices or templates). Use scope to stop regional teams changing other regions.
• AAA first, local last: Cisco recommends trying TACACS+ or RADIUS before local accounts, with SSO and Duo MFA wherever possible. Keep one local netadmin account as break-glass with a vaulted password.
• Hardened passwords: enable Configure Hardened Passwords at high (15 to 32 characters, no reuse of the last five, at least eight characters changed) and Configure Account Lockout.
• Change built-in credentials: change the default admin password at first login and replace the default configuration database login with a unique one (Update Configuration Database Login, or request nms configuration-db update-admin-user, which restarts the application server).
• Sessions: shorten the server session timeout (default 30 minutes), CLI idle-timeout (default 1800 seconds) and session lifetime (default 24 hours), and set maximum sessions per user role.
• SSH: key-based only, RSA 2048 to 4096 bits, at most two keys per user, private keys only on admin or jump hosts and never on Validators or Controllers, removed immediately at offboarding. See the SSH Key Management Guide.

Integrations, API tokens and service accounts

SD-WAN Manager exposes a REST API under /dataservice/ that automation, monitoring and orchestration tools call with user credentials. Cisco's hardening guide does not give separate API token guidance, so control the API through the accounts that use it.

• Dedicated automation users: give each tool its own user with a custom role holding only the features it needs, ideally read-only. CVE-2026-20122 shows a read-only API account is still worth protecting.
• Vault the credentials: store automation passwords in a secrets manager, rotate them on a schedule and after every Manager advisory, and never embed them in scripts. See the Secrets Management Guide.
• Source restriction: automation should reach TCP 443 only from known management hosts, the same as people.
• Configuration database and DCA: record who knows the configuration database credentials (all cluster nodes must match), and on releases before 20.18 treat the DCA credential as exposed if the Manager was reachable before patching.
• Integration secrets: Umbrella API keys, cloud on-ramp credentials and SNMPv3 users are held in Manager configuration. Inventory them with owners. Use SNMPv3 only.
• Certificates: replace the self-signed web server certificate with one from your enterprise or a public CA, and choose the controller certificate authorisation mode deliberately (Cisco PnP, manual or Enterprise CA). Device certificates are the control plane identity: an unexpected certificate or serial is an incident.

Management plane exposure and ports

Most of the 2026 risk came from reachable control components. Cisco's hardening guide gives this allow list.

• Self-hosted: put VPN 0 (transport) interfaces in a DMZ behind a perimeter firewall with 1:1 NAT, and VPN 512 (management) in an isolated out-of-band VLAN. Administrators reach it from a hardened jump host through an MFA-protected VPN.
• Cisco-hosted: use Inbound Rules in the Catalyst SD-WAN Portal; never use the ALL rule for source or port; each fabric allows up to 200 rules. Add a localised policy on VPN 512 to narrow further.
• Static edges: if edges have known public addresses, restrict control plane sources to those blocks; with NAT in the underlay, source ports may be randomised.

See the Network Device Management Plane Hardening Guide for the general principles.

Logging and detection

Forward syslog over TLS to a remote collector, and set audit log retention under Administration, Settings, Statistics Database Configuration (Cisco suggests sizing with the /dataservice/management/elasticsearch/index/size/estimate API plus about 20 per cent headroom). Audit logging records configuration changes, template attach and detach and logins.

If indicators appear, Cisco's guidance is to run admin-tech on each control component and open a TAC case before changing anything, so evidence is preserved. See the Network Device Syslog and Configuration Change Detection Guide.

Metrics:

• Control components with TCP 22, 443 or 830 reachable from the internet (target zero, verified by external scan).
• Days from a Cisco SD-WAN KEV addition to fixed release on every control component.
• Number of netadmin users and of local accounts other than break-glass.
• Unexplained vmanage-admin logins or unknown peers per month (target zero, every one investigated).
• Percentage of automation users with custom roles and vaulted, rotated credentials.
• Audit log and syslog coverage and retention, against the configured target.

Known exploited SD-WAN Manager vulnerabilities

Cisco SD-WAN entries added to the CISA KEV catalogue in 2026 (catalogue version 2026.10.21). The short gap between "added" and "due" for federal agencies shows how CISA rated them.

The KEV entries for the February to May 2026 flaws direct agencies to Emergency Directive 26-03 and its supplemental hunt and hardening direction. Outside the US federal sector the lesson is the same: a Manager flaw on the KEV list is an incident-response event with a hunt step, not a routine patch. See the Vulnerability Management for Network Devices Guide.

Hardening baseline

1. Patch level: run a fixed release on every Manager, Controller and Validator. For CVE-2026-20127 Cisco lists 20.9.8.2, 20.12.5.3 or 20.12.6.1, 20.15.4.2 and 20.18.2.1, and says releases earlier than 20.9 must migrate. Several 20.x trains have reached End of Software Maintenance: plan to leave them.
2. Exposure: apply the port allow list above; no administrative port reachable from the internet.
3. Authentication: AAA or SSO with MFA, local accounts last, hardened passwords high, account lockout, default admin and configuration database credentials changed.
4. Roles: custom roles with scope; netadmin for a few named people.
5. Crypto and services: replace the self-signed web certificate, keep DTLS or TLS control connections, keep FIPS mode (default on control components from 20.15.1), SNMPv3 only, and disable weak SSH algorithms (SHA-1, AES-128, AES-192) once all devices support it.
6. Logging: syslog over TLS off-box, audit retention sized, alerts on the indicators above.
7. Backups: configuration database backups from the leader node, stored encrypted, noting that restore is only supported to the same software version.

Responding to an SD-WAN Manager advisory

1. Restrict first: limit ports 22 and 830 (and 443) to known controllers and management hosts as Cisco's temporary mitigation, testing in your environment because Cisco warns it may affect functionality.
2. Collect evidence: run admin-tech on each control component before upgrading or rebooting.
3. Hunt: run Cisco's verification checks: unknown peers, vmanage-admin logins, DCA reads, licensing upload traversal and *.jsp requests.
4. Upgrade: to the fixed release within your major train unless TAC advises otherwise. Rescan admin-techs with Cisco's bug applicability tool for newer indicators.
5. Rotate: change local and automation passwords, the configuration database login, SSH keys and any secrets pushed through templates. Cisco's remediation note leaves credential rotation to TAC guidance, so agree the list with TAC.
6. Rebuild if compromised: Cisco's rebuild procedure uses fresh images from software.cisco.com, new system IPs, new controller certificates, changed default credentials, a configuration database restore to the same version, and invalidating old controllers from the Certificates page only after all control and BFD sessions are up. That last step is your rollback point: keep the old controllers valid until the new fabric is proven.

Small deployments on Cisco-hosted SD-WAN should focus on portal inbound rules, SSO with MFA and role reduction, since Cisco states hosted environments already have guardrails for CVE-2026-20127. Large self-hosted fabrics need the full DMZ and out-of-band design, a tested rebuild runbook and a named owner for every internal account.

Common misconfigurations

• Manager UI and NETCONF reachable from the internet: the single biggest factor in exposure to the 2026 flaws.
• Using the ALL inbound rule in the hosted portal: it reopens everything the portal could restrict.
• Default configuration database credentials: neo4j/password left in place on clusters.
• Everyone in netadmin: operators and automation tools given full control because custom roles were never built.
• Patching without hunting: upgrading a compromised Manager leaves the attacker's access and changes in place.
• Logs only on the appliance and short audit retention: peering and login evidence is gone before anyone looks.

Framework mapping

Practitioner checklist

• Confirm every Manager, Controller and Validator runs a fixed release for CVE-2026-20127 and the Manager API advisory.
• Scan from the internet and confirm TCP 22, 443 and 830 are not reachable; apply the Cisco port allow list.
• Run Cisco's indicator checks for unknown peers, vmanage-admin logins and web shell paths, and keep the admin-tech output.
• Move administrators to TACACS+, RADIUS or SSO with MFA and keep a single vaulted local break-glass account.
• Build custom roles for operators and automation, and reduce netadmin to named individuals.
• Change the default configuration database login and rotate automation and SSH credentials.
• Replace the self-signed web certificate and review controller certificate authorisation settings.
• Forward syslog over TLS, size audit log retention and alert on the indicator table.
• Write and rehearse the fabric rebuild runbook before you need it.

Standards and references

• Cisco: Catalyst SD-WAN Hardening Guide
• Cisco: Catalyst SD-WAN Controller Authentication Bypass Vulnerability (CVE-2026-20127)
• Cisco: Catalyst SD-WAN Manager Vulnerabilities advisory
• Cisco: Remediate Catalyst SD-WAN Security Advisory
• Cisco: Rebuild Your Catalyst SD-WAN Fabric
• CISA: Known Exploited Vulnerabilities Catalog
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls

Related NHI Mgmt Group resources: SD-WAN Security Guide · Network Device Management Plane Hardening Guide · Cisco IOS XE Hardening Guide · Vulnerability Management for Network Devices Guide