Before you begin
- A Atlas AVD plan. The Integrations hub is not available on Community
- The Administrator role in Atlas to connect, configure or disconnect a connector. Integrations appears under Administration only for administrators
- A tenant selected in the tenant picker. Credentials are stored encrypted per tenant, so each tenant you manage connects its own account
- Firewalls managed in SonicWall Network Security Manager SaaS (US or Europe)
- A MySonicWall API key with MySonicWall API access enabled (MSSP partners have it by default)
- To sync into Vault: a Vault admin and at least one asset template (the Network Device template is a good fit)
What you can do
- Document every SonicWall firewall, HA standby and SonicWave access point as an Atlas Vault asset, with no manual data entry.
- Connect once with a MySonicWall API key to cover every customer tenant you manage in NSM.
- Map each MySonicWall tenant to the customer company it belongs to.
- Keep the documentation current: every hour Atlas adds new devices, updates changed details and archives devices NSM no longer reports.
- See what changed and when: firmware, management IP, MAC address, name, HA role and access point placement changes, each with the previous value kept.
- Ask Atlas Advisor about documented equipment, for example "Which SonicWall firmware versions do we have?"
Step 1: Create a MySonicWall API key
- Sign in to MySonicWall, go to My Workspace → User Groups → User List and click Generate API Key. Copy the key when it is shown; it is shown only once and is valid for a year by default.
- The key acts with the permissions of the MySonicWall user it belongs to, and can reach every tenant that user can. Create it for a user whose user group only covers the tenants Atlas should document.
- MSSP partners have MySonicWall API access by default. If yours is not enabled, ask SonicWall to turn on the MySonicWall API token permission for that user.
- Note which Network Security Manager region you sign in to: nsm-uswest.sonicwall.com (US) or nsm-eucentral.sonicwall.com (Europe).
Step 2: Connect in Atlas
Once connected, the card shows Manage, which opens Atlas Vault → Assets, and Disconnect. The key is stored encrypted and is never shown again. It is only ever sent to MySonicWall; Atlas opens a short-lived Network Security Manager session for each sync and never stores it.
- Select the tenant in the tenant picker.
- Go to Administration → Integrations and click Connect on the SonicWall card.
- Choose your Network Security Manager region.
- Paste the MySonicWall API key.
- Click Connect. Atlas lists your MySonicWall tenants with the key before saving anything; if it is rejected, nothing is stored.
Step 3: Map each tenant to a company
Add one sync per tenant. Each tenant can be mapped only once in an Atlas tenant, so its equipment never ends up under two companies.
- Open Atlas Vault → Assets → RMM & PSA sync and click Add sync.
- Source: SonicWall.
- Device type: pick a tenant. Only MySonicWall tenants with Network Security Manager are listed.
- Template: pick Network Device. Atlas fills in the field mappings for you: Name, Type, Manufacturer, Model, Serial Number, Management IP, MAC Address and Firmware Version. You can change or add any mapping.
- Company: the customer this tenant belongs to.
- Leave Sync automatically every hour on, click Save Changes, then click Run now to document it straight away.
What gets documented
- Identity: name, manufacturer (SonicWall), model, product code and serial number, and an access point's MAC address.
- Type: Firewall or Access Point, and the product line (TZ, NSa, NSsp or NSv Series, SonicWave or SonicPoint).
- Network: the firewall's management address in NSM, and an access point's IP address, port and zone.
- Software: SonicOS firmware version and ROM version.
- Operational: online or offline, and the HA role (primary or secondary) with the partner unit's serial number.
- Placement: the firewall an access point is managed by, and the MySonicWall tenant.
Firewalls are matched by serial number and access points by MAC address, so renaming a device or changing its IP updates the same asset instead of creating a new one. Atlas never reads or keeps firewall admin passwords, authentication codes, registration codes or licence keys. Connected clients and firewall policy are not documented.
Your own documentation is kept
Atlas only fills the fields you map. Notes, attachments, custom fields and anything else you add in Vault are yours and are never touched. If you edit a mapped field by hand, Atlas keeps your value; if SonicWall later reports something different, the field is flagged under Drift to review so you can choose which to keep. A device NSM stops reporting is archived, not deleted, and comes back automatically if it returns. Atlas archives a device only after a complete read, so an offline firewall, an outage or a rejected key never empties your documentation.
Change history
Open an asset's ⋯ menu and choose History to see what changed: when the device was first documented, a new name, model, management IP, MAC address, firmware, HA role, managing firewall or zone (each with the previous and new value), when it was no longer reported, and when it came back. Routine online and offline changes are not recorded. The same entries appear on the Operations Timeline.
Ask Atlas Advisor
Atlas Advisor answers questions from the documented assets, read-only and limited to what you can see in Vault, with or without an AI provider. For example: "list our SonicWall firewalls", "Which SonicWall firmware versions do we have?", "Which SonicWave access points are offline?" or "Is SonicWall connected?".
What the integration does not do
- It is read-only. It never changes configuration, deploys templates, fails over an HA pair or upgrades firmware.
- It does not document connected clients or firewall policy.
- It reads firewalls through Network Security Manager SaaS only; firewalls not managed in NSM, or NSM on-premises, are not read yet.
- It syncs every hour or when you click Run now; the interval cannot be changed.
- It connects one MySonicWall API key per Atlas tenant. Credentials cannot be edited in place: disconnect and connect again with the new key.
GCC High tenants
On a tenant or deployment in Azure Government (GCC High), calls to SonicWall are blocked by default, because they can carry VM, host-pool and tenant names to a service outside the Government boundary. Connect fails with an Azure Government (GCC High) egress boundary message and nothing is stored, and pages that read from SonicWall stay empty. The operator who runs your Atlas deployment can approve SonicWall as a destination that is allowed to receive that data; once approved, the connector works normally. Running in Azure Government does not by itself make a third-party integration GCC High or CMMC compliant.
Disconnecting
Click Disconnect on the card and confirm. Atlas deletes its stored copy of the API key and pauses every Atlas Vault sync from SonicWall. The documented assets and their history stay in Vault; turn the syncs back on after you reconnect. Nothing changes in MySonicWall or Network Security Manager. Delete the API key in MySonicWall too if you no longer need it.
Troubleshooting
- The connection test fails with 401: the key is wrong, expired or revoked, or MySonicWall API access is not enabled for its user.
- A tenant is missing from the Device type list: it has no Network Security Manager, or the key's user cannot see it.
- A firewall's access points are missing: the firewall was offline or not reachable through NSM during the sync. Its existing access points are kept and refresh once it is back.
- SonicWall is temporarily rate limiting requests: scheduled syncs wait and retry on their own; try again in a few minutes.
- A sync reports the integration is not configured: SonicWall was disconnected. Connect it again, then turn the sync back on.