SonicWall Firewall and SMA Hardening Guide: Admin Access, VPN and MFA

SonicWall firewalls and Secure Mobile Access (SMA) appliances sit on the internet edge holding VPN accounts, directory bind credentials, pre-shared keys and OTP seeds, and attackers have repeatedly turned those stored secrets into access that outlives the patch. CISA's Known Exploited Vulnerabilities catalogue (version 2026.10.21) lists 19 SonicWall entries across SonicOS, SMA 100, SMA 1000 and Email Security, and in 2025 SonicWall confirmed that firewall configuration backups held in its cloud backup service had been accessed. This guide covers SonicWall-specific hardening: management access, administrator and VPN identities, the credentials a SonicOS configuration stores, logging, and how to recover when those credentials are exposed. It is for network and security engineers who run SonicWall in small and mid-sized estates. General VPN appliance practice is in the VPN Security Guide, which this page does not repeat. Menu paths and steps were checked against SonicWall knowledge base articles on 27 October 2026.

Key takeaways

• The configuration file is a credential vault. A SonicOS preferences file holds local passwords, TOTP bindings, LDAP, RADIUS and TACACS+ secrets, IPsec pre-shared keys, AWS keys and more, and SonicWall notes some routing authentication tokens are not encrypted in it.
• Patching does not remove stolen secrets. Google Threat Intelligence Group reported that an actor used administrator credentials and OTP seeds stolen before patching to regain access to fully patched SMA 100 appliances.
• Management and VPN belong behind allowlists. SonicWall's own containment steps start with disabling or restricting WAN management, SSL VPN, IPsec and inbound WAN rules to trusted addresses.
• Reset in a set order. SonicWall's remediation playbook puts core authentication (local users, TOTP, directory bind secrets) first, then VPN keys, then cloud integrations, then the long tail.
• Treat KEV entries as emergencies. CISA marks several SonicWall entries, including CVE-2024-40766 and CVE-2024-53704, as known to be used in ransomware campaigns.

How identity and access work in SonicWall

A SonicWall deployment has more identities than most teams inventory. Each can be an entry point, and each is stored in the appliance configuration.

On SMA appliances the same pattern holds: local and directory user credentials, session tokens and OTP seeds are stored on the appliance, and GTIG names CVE-2024-38475 as a vulnerability that exposes the SMA 100 databases holding them. See the Non-Human Identity (NHI) Guide for managing the service accounts and keys in this table as a governed population.

Admin roles and privileged access

• Use named administrators: SonicOS provides built-in administrator groups with full, limited and read-only rights. Give each engineer a named account in the right group, keep the default admin account for break-glass only, and give monitoring tools read-only access.
• Directory-backed admins with MFA: authenticate administrators through RADIUS or LDAP to a directory where MFA and leaver processes apply, with TOTP on any remaining local account. See the MFA Guide.
• Management plane only from management networks: disable HTTP, HTTPS and SSH management on WAN interfaces (NETWORK | System | Interfaces) or limit them to trusted addresses. Manage remote firewalls through NSM or a VPN from a management network, not from the internet.
• Disable SNMP if unused: SonicWall's containment guidance disables SNMP (DEVICE | Settings | SNMP); if you need it, use SNMPv3 users with unique passwords and restrict the monitoring hosts.
• Force password changes after resets: SonicOS 6.5.5.1 and 7.3.0 and later can restrict an account until the user changes their password, which closes the gap between a reset and the user's next sign-in.
• MySonicWall account: protect the portal account with MFA and limit who in your organisation, and at your MSP, can download or restore configuration backups.

For MSP-managed estates, insist on per-customer administrator accounts and on knowing where your configuration backups are stored. See the PAM Maturity Model.

Integrations, API tokens and service accounts

Every integration on a SonicWall stores a secret that must be rotated when the device or its backups are exposed. SonicWall's remediation playbook groups them into a reset order that works well as a standing inventory.

• Least-privilege bind accounts: the LDAP bind account needs read access to the user and group attributes the firewall queries, not domain administrator rights. Give it a long random password held in your vault.
• Cloud keys: AWS keys used for log export or VPN integration should belong to a dedicated IAM user or role limited to that function.
• DPI-SSL CA: if the configuration is exposed, SonicWall's guidance is to create a new re-signing CA, push trust to clients and retire the old one.
• Backups: after any rotation, export a new preferences file and store it encrypted under your control, and decide whether vendor cloud backup is acceptable for a file that contains every one of these secrets.

See the Secrets Management Guide for vaulting and rotating the secrets above.

Logging and detection

SonicOS writes System Logs and Auditing Logs (MONITOR | Logs). Send both to syslog or a SIEM so retention and integrity do not depend on the appliance. GTIG observed a rootkit on SMA 100 that deleted its own entries from local logs, which is why off-box logging matters.

After a VPN sign-in, watch what the session does: Huntress, reporting the SonicWall SSL VPN Account Compromises of October 2025, saw more than 100 accounts across 16 environments used with valid credentials, some followed by network scanning and attempts on local Windows accounts. See the VPN and Firewall Log Detection Guide.

Metrics:

• Number of SonicWall devices with WAN management enabled (target zero, or allowlisted only).
• Percentage of SSL VPN and administrator accounts with MFA enforced.
• Days from a SonicWall KEV addition to patch or mitigation, per device.
• Number of SMA or firewall models past end of support still in service.
• Percentage of stored integration secrets with a named owner and a rotation date.
• Log forwarding coverage: devices sending System and Auditing Logs off-box.

Known exploited SonicWall vulnerabilities

A selection of SonicWall entries in the CISA KEV catalogue (version 2026.10.21), most recent first. Check the vendor advisory for fixed versions and workarounds for each.

The pattern is consistent: the SSL VPN and the SMA portals are the exposed surface, and the follow-on risk is the credentials stored behind them. Two practical rules follow. First, if a KEV entry affects a device you could not patch before it was listed, assume the stored secrets may have been read and plan a reset. Second, reduce what is reachable: an SSL VPN restricted to known source addresses or replaced by per-application access removes most of this table from your risk. Exploitation of these flaws maps to ATT&CK T1190 Exploit Public-Facing Application, and reuse of the stolen credentials to T1078 Valid Accounts.

Hardening baseline

1. Inventory and lifecycle: list every firewall and SMA appliance with model, firmware and support status. Plan replacement for end-of-life devices; GTIG's SMA 100 report concerned fully patched end-of-life appliances.
2. Exposure: restrict WAN management, SSL VPN and IPsec to known addresses where the user base allows, and disable inbound WAN access rules that are not needed (POLICY | Access Rules).
3. Patching: track SonicWall security advisories and the CISA KEV catalogue; apply KEV-listed fixes or the published workaround within days, not the normal cycle.
4. Authentication: MFA on SSL VPN and all administrator accounts, directory-backed administrators, forced password change after resets.
5. Secrets: unique PSKs per tunnel, least-privilege bind accounts, dedicated cloud keys, and an owner for every stored secret.
6. Logging: System and Auditing Logs to syslog or SIEM, with alerting on the signals above.
7. Backups: encrypted, access-controlled preference exports under your control; review use of vendor cloud backup.

When credentials or backups are exposed

1. Contain first: SonicWall's essential credential reset article says containment must be complete before remediation: restrict or disable WAN management, SSL VPN, IPsec, inbound WAN rules and SNMP.
2. Preserve evidence: for suspected appliance compromise, GTIG recommends taking disk images before investigating, because a rootkit can hide files and edit logs. Export logs before reboots.
3. Reset by group: follow the seven groups above, starting with local users and TOTP, then VPN keys. SonicWall publishes an online analysis tool and an offline credentials reset tool to prioritise the work.
4. Rotate everything stored on the device: for SMA, GTIG calls resetting all passwords and OTP bindings the most critical step, plus revoking and reissuing certificates whose private keys are on the appliance.
5. Verify and roll back safely: test authentication, site-to-site and client VPN, monitoring, wireless and email alerts after each group, and keep a documented rollback for each change window.
6. Reopen gradually: restore VPN and management access only to allowlisted sources, then watch for authentication failures and unusual sign-ins.

For a small business with one firewall, the minimum is: no WAN management, MFA on SSL VPN, current firmware, and a stored list of every secret in the configuration so a reset can be done in one evening. Larger estates should manage SonicWall centrally through NSM, keep configuration exports in their own vault, and rehearse the reset playbook.

Common misconfigurations

• Patched but not rotated: credentials stolen through an earlier vulnerability still work after the firmware update. Every SonicWall emergency patch should come with a decision on credential rotation.
• Backups treated as harmless: the MySonicWall cloud backup incident showed that configuration files are a single store of most secrets on the network edge.
• Single-factor SSL VPN: valid passwords from any source, whether phishing, reuse or a stored configuration, open the VPN directly.
• Domain admin as LDAP bind account: a leaked firewall configuration then exposes a domain administrator password.
• End-of-life SMA left in service: no further fixes, and stolen OTP seeds remain valid until rebound.
• Logs only on the box: anti-forensic tooling and reboots erase the evidence you need for scoping.

Framework mapping

Practitioner checklist

• Inventory every SonicWall firewall and SMA appliance with firmware and support status, and schedule end-of-life replacements.
• Disable or allowlist WAN management, SSL VPN and IPsec, and remove unneeded inbound WAN rules.
• Enforce MFA on SSL VPN and all administrator accounts and move administrators to directory-backed, named accounts.
• Build a register of every secret stored in each configuration, mapped to SonicWall's seven reset groups, with owners.
• Replace domain-privileged LDAP bind accounts with least-privilege ones and use unique PSKs per tunnel.
• Check MySonicWall for devices listed in the cloud backup incident and confirm their credentials were reset.
• Forward System and Auditing Logs off-box and alert on rapid multi-account VPN sign-ins and configuration exports.
• Track SonicWall entries in the CISA KEV catalogue and patch or mitigate within days.
• Rehearse the containment, reset and verification playbook once a year.

Standards and references

• SonicWall: Essential Credential Reset
• SonicWall: Remediation Playbook
• SonicWall: MySonicWall Cloud Backup File Incident
• CISA: Known Exploited Vulnerabilities Catalog
• Google Threat Intelligence Group: SonicWall SMA exploitation and the OVERSTEP backdoor
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls

Related NHI Mgmt Group resources: VPN Security Guide · VPN and Firewall Log Detection Guide · Akira Threat Actor Profile · SonicWall SSL VPN Account Compromises