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
- Sophos Firewalls registered in Sophos Central (Firewall Management)
- A Sophos Central API credential (client ID and secret) for a partner, an enterprise organization or a single tenant
- 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 Sophos Firewall and HA peer as an Atlas Vault asset, with no manual data entry.
- Connect once with a partner or enterprise API credential to cover every customer tenant you manage in Sophos Central.
- Map each Sophos Central tenant to the customer company it belongs to.
- Keep the documentation current: every hour Atlas adds new firewalls, updates changed details and archives firewalls Sophos Central no longer reports.
- See what changed and when: firmware, external IP, name, hostname, model, HA role and firewall group changes, each with the previous value kept.
- Ask Atlas Advisor about documented equipment, for example "What firmware are our Sophos XGS devices running?"
Step 1: Create a Sophos Central API credential
- As a tenant admin, sign in to Sophos Central and go to Global Settings → API Credentials. As a partner, go to Settings & Policies → API Credentials. Enterprise (organization) admins use the API Credentials page of their enterprise dashboard.
- Click Add Credential, give it a name such as Atlas AVD, and pick a read-only role. Atlas only reads tenants and firewall inventory.
- Copy the client ID, then reveal and copy the client secret. The secret is shown only when the credential is created.
- A partner credential reaches every tenant the partner manages and an organization credential every tenant in the organization. A tenant credential reaches only its own tenant.
Step 2: Connect in Atlas
Once connected, the card shows Manage, which opens Atlas Vault → Assets, and Disconnect. The client ID and secret are stored encrypted and are never shown again. The secret is only ever sent to Sophos, which exchanges it for a token that lasts an hour; Atlas never stores that token.
- Select the tenant in the tenant picker.
- Go to Administration → Integrations and click Connect on the Sophos Central card.
- Paste the client ID and the client secret.
- Click Connect. Atlas signs in with the credential and lists the tenants it can read 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: Sophos Central.
- Device type: pick a tenant.
- Template: pick Network Device. Atlas fills in the field mappings for you: Name, Type, Manufacturer, Model, Serial Number, Management IP 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, hostname, manufacturer (Sophos), model (for example XGS2100), serial number and the firewall's Sophos Central ID.
- Type: Firewall, and the product line (XGS, XG or SG Series, or Virtual / Cloud).
- Network: the firewall's external IPv4 addresses.
- Software: the SFOS firmware version.
- Operational: online, offline or suspended, and whether Sophos Central manages it.
- High availability: the mode (active-passive or active-active), the role (primary, auxiliary or fault) and the peer's serial number.
- Placement: the Sophos Central firewall group and tenant.
Firewalls are matched by serial number, so renaming a firewall or changing its IP updates the same asset instead of creating a new one. Sophos switches and wireless access points are not documented yet: Sophos Central's public API does not list them. Atlas does not keep who created or changed a firewall in Sophos Central or its map location. Firewall rules, users and connected clients 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 Sophos Central later reports something different, the field is flagged under Drift to review so you can choose which to keep. A firewall Sophos Central stops reporting is archived, not deleted, and comes back automatically if it returns. Atlas archives a firewall only after a complete read, so an outage or a rejected credential never empties your documentation.
Change history
Open an asset's ⋯ menu and choose History to see what changed: when the firewall was first documented, a new name, hostname, model, external IP, firmware, HA role, HA peer or firewall group (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 Sophos firewalls", "What firmware are our Sophos XGS devices running?" or "Is Sophos Central connected?".
What the integration does not do
- It is read-only. It never changes configuration, imports or exports a configuration, runs a firewall action or upgrades firmware.
- It does not document Sophos switches or wireless access points yet, firewall rules, users or connected clients.
- It reads firewalls registered in Sophos Central only.
- It syncs every hour or when you click Run now; the interval cannot be changed.
- It connects one Sophos Central API credential per Atlas tenant. Credentials cannot be edited in place: disconnect and connect again with the new credential.
GCC High tenants
On a tenant or deployment in Azure Government (GCC High), calls to Sophos Central 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 Sophos Central stay empty. The operator who runs your Atlas deployment can approve Sophos Central 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 credential and pauses every Atlas Vault sync from Sophos Central. The documented assets and their history stay in Vault; turn the syncs back on after you reconnect. Nothing changes in Sophos Central. Delete the API credential in Sophos Central too if you no longer need it.
Troubleshooting
- The connection test fails: the client ID or secret is wrong, or the credential was deleted in Sophos Central. Create a new credential and connect again.
- A tenant is missing from the Device type list: the credential cannot see it. A tenant credential only lists its own tenant; use a partner or enterprise credential to reach several.
- A firewall is missing: it is not registered in Sophos Central Firewall Management.
- Sophos 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: Sophos Central was disconnected. Connect it again, then turn the sync back on.