Since the day Sophos was founded, security has remained principal in everything we do; inside and out. This security-first approach is why hundreds of thousands of organizations secure hundreds of millions of devices with Sophos solutions.

Sophos Central is our flagship, cloud-based security platform, designed from the ground-up to deliver state-of-the-art security technology while ensuring customer data is protected effectively and comprehensively.

This document will take a detailed look into Sophos Central, its development, deployment, and maintenance as well as what data is collected, where it is stored, how that data is protected, and various other measures Sophos takes to provide the industry’s most advanced and fortified security platform.

Secure Development

Security begins at conception and should never be an after-thought. Key to this is Sophos’ activity-based Secure Development Lifecycle (SDL). The SDL procedurally enforces industry-leading best practices throughout the entirety of a product’s development.

The SDL also requires that all product development teams have an embedded security advocate and expert that drives these activities within their team. Below are a number of those activities with a brief explanation.

The purpose of each activity is to identify areas of risk before a product is released. This maximises the total possible time that an engineering team can have to address issues long before shipping products and services to customers.

Secure Coding

To guard against, and significantly reduce, accidental introduction of software vulnerabilities, engineers are trained to identify and avoid insecure coding practices and design patterns, leveraging more resilient designs in their place.

Vulnerability Dependency Framework

Where code from third-parties, such as open source software, is leveraged in products, each team maintains a list of third-party dependencies within a framework that automatically alerts the team if a CVE is published. This ensures the teams can produce and release a patch as quickly as possible in the event a vulnerability is found within third-party code.

Threat Modeling

Systematic analysis of any design or implementation of a system or component is performed from the perspective of a probable attacker. Threats are identified by looking at the avenues an attacker would take, what they would recognize as weaknesses, and what methods they would use to exploit it. A level of risk is assigned to each threat, enabling them to be prioritized, so that appropriate controls, mitigations, or redesigns can be put in place.

Static Analysis

Automated tools are used to analyse the source code, quickly highlighting any coding errors, vulnerabilities, flawed or weak design patterns. In addition to automated tools, we practice pair programming with human code reviews and peer reviews during the development cycle.

Internal Security Test Plans

An extensive test plan is developed by every team working on a system or component. This plan covers both white-box and black-box testing; unit, integration, and system tests; code coverage, functional testing, fuzzing, use case testing, and more.

External Security Testing

We regularly have reputable, external testers or penetration testers conduct white-box testing of our codebase to identify threats we haven’t found.

Vulnerability Response Plan

In the event that a vulnerability is found within our products, either via internal testing, external testing, or via our bug-bounty program, procedures are followed to rapidly respond to any vulnerability and a patch or update can be promptly developed, quality assured, and released.

Secure Code Signing

In addition to signing executables, which is common for endpoint software, in Sophos Central, we leverage code signing prior to deployment to customer-facing systems, to guarantee that no code modifications or corruptions occur after being signed. This ensures our quality assured code is the same code customers receive and use.

Sophos Central platform

Sophos Central is hosted on Amazon Web Services, across a number of virtual machine instances and services that dynamically scale to handle the current Sophos Central workload.

When you create a Sophos Central account, you will be provided with the choice of region where you set up your account. These regions are completely independent, and data is not moved between them.

At present, the options are Germany, Ireland, and the United States. Sophos Central regions are synonymous with AWS Regions; EU-Central-1, EU-West-1, US-East-2 and US-West-2.

Sophos Central is a cloud native application and has worked deeply with our partner Amazon to build a highly available and durable application. All data is geo-fenced in the customer selected region. Within that region we employ replication across multiple data centers (availability zones), provided by Amazon, to provide seemly failover in the event of infrastructure-level failures. All customer data is locked to a region and cannot be transferred across regions.

Sophos Central uses well-known, widely used, and industry standard software libraries to mitigate common vulnerabilities (covered in the OWASP Top Ten). By leveraging standard libraries, we benefit from the high level of scrutiny they face not just in terms of security but stability as well.

Figure: Sophos Central Architecture

Physical Security

As the physical infrastructure for Sophos Central is maintained by Amazon, there is a separation of responsibilities. In brief, Amazon take responsibility for security of the cloud itself, and Sophos take responsibility for security in the cloud. The AWS Shared Responsibility Model details these responsibilities:

For details on what steps Amazon takes to secure the infrastructure and services they offer, see their security whitepaper:

Network Security

Runtime Application Self-Protection

In addition to standard network security practices such as firewalling, Sophos Central uses Runtime Application Self-Protection (RASP) technology. As an alternative to a typical perimeter defense, RASP monitors inputs to detect and block attacks on Sophos Central by leveraging real-time knowledge from within the inner workings of the application itself. By using RASP, Sophos Central can dynamically respond to attacks, preventing exploitation, and take further actions such as terminating a session or alerting security teams, keeping customer data secured at all times.

Auto-Scaling Virtual Networks

Sophos Central is segmented into a number of logically separate virtual networks based on the various workloads they perform (such as authentication or endpoint management). All workloads are then placed into auto-scaling groups, behind a load balancer, so that when a particular workload sees increased load/traffic, additional, temporary resources can be allocated to give the group capacity to handle the load.

Network Access Control Lists

Security Groups and Network Access Control Lists are in place using the principle of least privilege. By default, any service that is built for use in Sophos Central is placed on a private subnet that is not exposed outside of the virtual network. Additionally, services are not given permission to talk to other services unless explicitly needed and access has been granted by the Sophos Central Infrastructure Services (CIS) team. Only services that must expose an external interface are given a public-facing interface.

Database Access

Databases are not exposed to the internet, are only accessible within the virtual network, and are kept on separate, private subnets from the other Sophos Central infrastructure. Services wishing to interact with any database must do so through the Data Access Layer (DAL). More on the DAL can be found in the Data Security section of this document.

Maintenance Access

Maintenance access to Sophos Central is only available via a VPN tunnel originating from a specific network within Sophos’ IT infrastructure. The tunnel cannot be established outside of Sophos’ network even with credentials, keys, and certs.

DDoS Protections

Distributed Denial of Service (DDoS) mitigations are made via dedicated DDoS protection technologies, autoscaling, system monitoring, and traffic shedding.

Data Security



Every piece of data is stored in database clusters that is, at a minimum, triplicated. Event-driven clustered replication, with a replication factor of at least three, ensures two database instances in our cluster can fail and data will still remain available. Being event-driven, any database change is immediately pushed to all instances in the cluster, rather than changes being replicated on a schedule, making sure that even when an instance fails, the full dataset is available on failover instances.


Each instance of a database is supported with its own storage volume which is snapshotted hourly. These instances are transient, with only the storage volumes persisting. This enables us to destroy database instances without fear of data loss thanks to the cluster replication factors. Vulnerabilities in database applications, operating systems etc can be rapidly addressed without data loss.


All data at rest is encrypted using volume-level encryption – storage volumes, object storage, and virtual drives of virtual machines.

For sensitive user data, we use field-level encryption within storage volumes using a per-field multi-part key. These parts are formed from several different locations, including a key management system. Each key is unique to every customer, and every field.

Transport-level encryption is used to secure management communication between the client software and Sophos Central platform via certificates and server validation.

Sophos never stores nor sends users’ passwords in plain text. When a user signs up for an account, this new user must set a password as part of the activation process.

Central Device Encryption

Sophos Central Device Encryption does not store encryption keys but, instead, recovery keys for BitLocker and FileVault-encrypted volumes.

Storing Keys

A recovery key is randomly generated on the Windows/Mac endpoints. This recovery key is obfuscated and sent to Sophos Central via our Management Communication System (MCS) protocol, protected with Transport Layer Security (TLS). Once it has reached Sophos Central, the recovery key is deobfuscated and stored in the relevant storage volume. The recovery key is transparently encrypted using AES, in addition to residing on an encrypted volume. Recovery key metadata is not stored alongside the recovery key.

Accessing Keys

As soon as an admin or user reads a recovery key from the database (such as via the Sophos Central Admin or Self Service Portal), this recovery key is marked as ‘expired’. When the recovery key is used to recover an endpoint, and the endpoint boots and synchronizes with Sophos Central, it is informed the recovery key is expired. The endpoint generates a new recovery key and sends this to Sophos Central as detailed above. Once Sophos Central confirms it has received the new recovery key, the old recovery key is invalidated on the endpoint so that it no longer can be used. This ensures that recovery keys can only be used once. Recovery keys are never deleted in Sophos Central.

Threat Protection


Sophos Central is architected so that all machines are user-less, requiring no interaction, allowing machines to be locked down and hardened. Machines are built from pristine sources, thanks in part to our secure digital code signing process, and only execute the prescribed software from engineering as part of creating the machine gold image.

Similarly, to database server instances, machines that comprise Sophos Central can be destroyed and rebuilt at any time without data loss.


Every 3 weeks, the gold images for virtual machines are upgraded with the latest software libraries and applications. No virtual machine instance exists for longer than 3 weeks, with old instances being destroyed and new instances deployed based on the new gold images.

Should a vulnerability be found via the vulnerability dependency framework, internal or external testing, bug bounty program, or other means, patching and redeployment take place as part of the vulnerability response program.

Security Monitoring and Response

Sophos’ global security team monitor all logging data from Sophos Central and its related services 24/7/365. Central has forensic capabilities in the event of a data breach for rapid incident response.

Compliance and external audits


Sophos regularly undergoes SOC Type 1 auditing and can provide access to the report under NDA. SOC Type 2 auditing is currently in progress.

Penetration testing

We regularly conduct both internal and external penetration testing with reputable third-parties and can provide attestation under NDA.


Sophos’ global commitment to data protection is detailed on our website:

Customer Controls

Multi-Factor Authentication (MFA)

MFA can be enabled for all administrators of a Sophos Central account, a subset of administrators, or disabled completely. We strongly recommend the use of MFA to ensure that, in the event of credentials becoming compromised, Sophos Central account access is not possible.

Role-Based Administration

A number of pre-defined administrative roles can be assigned to admins that can restrict access to sensitive log data as well as restrict them from making changes to settings and configurations.

Threat Protection Policy

Within a Threat Protection policy, an admin can enable or disable the following settings that expand or restrict the volume of data shared real-time with Sophos. Please see the Telemetry and Data Gathering section of this document for more detail.

Live Protection

  • Use Live Protection to check the latest threat information from SophosLabs online.
  • Use Live Protection during scheduled scans
  • Automatically submit malware samples to SophosLabs

Real-time scanning (Internet)

  • Block access to malicious websites
  • Detect low-reputation files


  • Enable Root Cause Analysis
  • Enable Snapshot file upload

Runtime Protection

  • Detect network traffic to command and control servers

Telemetry and Data Gathering

Full details on the data we gather and store are detailed on the following pages of our website:

Sophos Group Privacy Policy

SophosLabs Information Security Policy -information-security-policy.aspx.

Sophos Extensible List (SXL)

SXL is our protocol to provide supplementary data to devices, covering up-to-the-minute classifications from SophosLabs. This is typically performed by sending a hash, a URL, or file to SophosLabs and by receiving a response with further information on that URL or file. We use this protocol for several features:

Web Protection

Protects users from browsing to websites known to be hosting malicious code or used for dangerous means.

Web Control

Fetching the latest website category for use in on-endpoint web filtering.

Live Protection

Quickly identifying known malicious files and blocking them before they can execute as well as identifying and blocking attempted network communication to known-bad hosts. Live Protection is also used to ascertain the reputation of downloaded files.

False Positive Mitigation

Additional capability to suppress false positive detections via receiving information on known good files.

Root Cause Analysis

Sophos Data Recorder (SDR), part of Intercept X, logs all system activity of note. When a malicious detection is made, an automatic root cause analysis is generated using a snapshot of data from the SDR. The recorded data is used to correlate all activities related to the detection (files, processes, registry keys, URLs/IPs interactions) and upload these to Sophos Central.

In addition to root causes, snapshots can also be uploaded (disabled by default) which contain the same kinds of data as in a root cause but unrelated to the malicious detection. This feature is used primarily for support or debugging purposes, or to share data with engineering for product feature improvement.

Sample Submission

Malicious file samples can be submitted to SophosLabs automatically for further analysis. Currently, only malicious portable executables are retained, with other filetypes securely discarded.

Additional Measures

SophosLabs Isolation

Given the nature of the highly proprietary research, development, and daily operations within SophosLabs (such as investigating the latest malicious threats and development of machine learning models), SophosLabs is separated from other networks to minimize the the possibility of breaches. Additionally, all malware execution, analysis, and research is performed on separate, isolated systems to prevent infection. These isolation efforts ensure Sophos Central development is not exposed to risk.

Responsible Disclosure and Bug Bounty Programs

Sophos has a strong presence in the independent researcher community and runs a bug bounty program to reward researchers for their findings. Full details can be found in the Sophos Responsible Disclosure Policy: as well as our BugCrowd page:

Naked Security

Naked Security is Sophos’ award-winning security news blog that provides news, opinion, advice and research on computer security issues and the latest internet threats.

Our journalists and researchers provide another valuable avenue for insights and suggested improvements to our engineering efforts of Sophos Central.

Legal notices

Copyright © 2019 Sophos Limited. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording or otherwise unless you are either a valid licensee where the documentation can be reproduced in accordance with the license terms or you otherwise have the prior permission in writing of the copyright owner.

Sophos, Sophos Anti-Virus and SafeGuard are registered trademarks of Sophos Limited, Sophos Group and Utimaco Safeware AG, as applicable. All other product and company names mentioned are trademarks or registered trademarks of their respective owners.