AXIS OS Hardening Guide

AXIS OS Portal | AXIS OS Release Notes | AXIS OS Knowledge base | AXIS OS Security Advisories

Axis Communications strives to apply cybersecurity best practices in the design, development, and testing of our devices to minimize the risk of flaws that hackers could exploit in an attack. However, the entire vendor supply chain and end-user organization must be involved in securing a network, its devices, and the services it supports. A secure environment depends on its users, processes, and technology. The purpose of this guide is to help you keep your network, devices, and services secure.

The most obvious threats to an Axis device are physical sabotage, vandalism, and tampering. To protect a product from these threats, it’s important to select a vandal-resistant model or casing, to mount it in the recommended manner, and to protect the cables.

Axis devices are network endpoints just like computers and mobile phones. Many of them have a web interface that can expose vulnerabilities to connected systems. In this guide, we explain how you can reduce those risks.

The guide provides technical advice for anyone involved in deploying Axis solutions. It includes a recommended baseline configuration as well as a hardening guide that takes the evolving threat landscape into account. You may need to consult the product’s user manual to learn how to configure specific settings. Note that Axis devices got a web interface update in AXIS OS 7.10 and 10.9, which changed the configuration path.

Web interface configuration
The guide refers to configuring device settings within the web interface of the Axis device. The configuration path differs according to the AXIS OS version installed on the device:

This guide applies to all AXIS OS-based products running AXIS OS (LTS or active track) as well as legacy products running 4.xx and 5.xx.

The AXIS OS Security Architecture diagram outlines AXIS OS cybersecurity capabilities across various layers offering a comprehensive view of the security foundation, silicon-assisted security, AXIS OS operating system, and the application and access control layer.

Right click and open the image in a new tab for a better visual experience.

We recommend that you subscribe to Axis security notification service to receive information about newly discovered vulnerabilities in Axis products, solutions, and services as well as how to keep your Axis devices secure.

We follow the methods outlined in the Center for Internet Safety (CIS) Controls Version 8 to structure our cybersecurity framework recommendations. The CIS Controls, formerly known as the SANS Top 20 Critical Security Controls, provide 18 categories of Critical Security Controls (CSC) focused on addressing the most common cybersecurity risk categories in an organization.

This guide refers to the Critical Security Controls by adding the CSC number (CSC #) for each hardening topic. For more information about the CSC categories, see the 18 CIS Critical Security Controls at cisecurity.org.

Axis devices come with default protection settings. There are several security controls that you don’t need to configure. These controls provide a base level of device protection and serve as the foundation for more extensive hardening.

CSC #4: Secure Configuration of Enterprise Assets and Software

The Axis device will not operate until the administrator password has been set. 

To learn how to configure device access, see Device access in AXIS OS Knowledge base.

After setting the administrator password, access to administrator functions and/or video streams is only possible via authentication of valid username and password credentials. We don’t recommend that you use features that enable unauthenticated access such as anonymous viewing and always multicast mode.

CSC #4: Secure Configuration of Enterprise Assets and Software

Only a minimal number of network protocols and services are enabled by default in Axis devices. In this table you can see which these are.

* For more information about edge-to-edge, see the white paper Edge-to-edge technology.

* *Allocated automatically within a predefined range of port numbers according to RFC 6056. For more information, see the Wikipedia article Ephemeral port.

We recommend that you disable unused network protocols and services whenever possible. For a complete list of services that are used by default or can be enabled based on configuration, see Commonly used network ports in AXIS OS Knowledge base.

For instance, you need to manually enable audio in/out and microphone functionality in Axis video surveillance products such as network cameras, while in Axis intercoms and network speakers, audio in/out and microphone functionality are key features and therefore enabled by default.

CSC #4: Secure Configuration of Enterprise Assets and Software

Every Axis device comes with a so-called physical UART (Universal Asynchronous Receiver Transmitter) interface, sometimes referred to as a ‘debug port’ or ‘serial console’. The interface itself is only physically accessible through extensive dismantling of the Axis device. The UART/debug interface is used only for product development and debugging purposes during internal R&D engineering projects within Axis.

The UART/debug interface is enabled by default in Axis devices with AXIS OS 10.10 and earlier versions, but it requires authenticated access and doesn’t expose any sensitive information while being unauthenticated. Starting from AXIS OS 10.11, the UART/debug interface is disabled by default. The only way to enable the interface is by unlocking it through a device-unique custom certificate provided by Axis.

Axis Edge Vault provides a hardware-based cybersecurity platform that safeguards Axis devices. It relies on a strong foundation of cryptographic computing modules (secure element and TPM) and SoC security (TEE and secure boot), combined with expertise in edge device security. Axis Edge Vault is based on a strong root of trust established by secure boot and signed firmware. These features enable an unbroken chain of cryptographically validated software for the chain of trust that all secure operations depend on.

Axis devices with Axis Edge Vault minimize customer exposure to cybersecurity risks by preventing eavesdropping and malicious extraction of sensitive information. Axis Edge Vault also ensures that the Axis device is a trusted and reliable unit within the customer’s network.

CSC #2: Inventory and Control of Software Assets

AXIS OS is signed from version 9.20.1. Whenever you upgrade the AXIS OS version on device, the device will check the integrity of the update files through cryptographic signature verification and reject any tampered files. This prevents attackers from luring users into installing compromised files.

For more information, see the white paper Axis Edge Vault.

CSC #2: Inventory and Control of Software Assets

Most Axis devices have a secure boot sequence to safeguard the integrity of the device. Secure boot prevents you from deploying Axis devices that have been tampered with.

For more information, see the white paper Axis Edge Vault.

CSC #6: Access Control Management

The secure keystore provides hardware-based, tamper-protected storage of cryptographic information. It protects the Axis device ID as well as cryptographic information uploaded by the customer, while also preventing unauthorized access and malicious extraction in the event of a security breach. Depending on security requirements, an Axis device can have one or multiple such modules, like a TPM 2.0 (Trusted Platform Module), a secure element, and/or a TEE (Trusted Execution Environment).

For more information, see the white paper Axis Edge Vault.

CSC #3: Data Protection

A malicious adversary could try to extract information from the filesystem by demounting the flash memory and accessing it through a flash reader device. However, the Axis device can protect the filesystem against malicious data exfiltration and configuration tampering in the event of someone gaining physical access to or stealing it. When the Axis device is powered off, the information on the filesystem is AES-XTS-Plain64 256bit encrypted. During the secure boot process, the read-write filesystem is decrypted and can be mounted and used by the Axis device. 

For more information, see the white paper Axis Edge Vault.

CSC #3: Data Protection

Starting from AXIS OS 7.20, HTTPS has been enabled by default with a self-signed certificate which enables setting the device password in a secure way. Starting from AXIS OS 10.10, the self-signed certificate was replaced by the IEEE 802.1AR secure device ID certificate.

AXIS OS has the most common security-related HTTP(S) headers enabled by default to improve the base level of cybersecurity in the factory default state. Starting from AXIS OS 9.80, you can use the custom HTTP header VAPIX API to configure additional HTTP(S) headers.

For more information about the HTTP header VAPIX API, see the VAPIX Library.

To read more about default HTTP(S) headers, see Default HTTP(S) headers in AXIS OS Knowledge base.

CSC #3: Data Protection

Clients accessing the device will authenticate with a password that should be encrypted when sent over the network. We therefore recommend that you only use Digest authentication instead of Basic or both Basic and Digest. This reduces the risk of network sniffers getting hold of the password.

CSC #3: Data Protection

Replay attack protection is a standard security feature enabled by default in Axis devices. Its purpose is to sufficiently secure ONVIF-based user authentication by adding an additional security header, which includes the UsernameToken, valid timestamp, nonce and password digest. The password digest is calculated from the password (which is already stored in the system), nonce, and timestamp. The purpose of the password digest is to validate the user and prevent replay attacks, which is why digests are cached. We recommend that you keep this setting enabled.

CSC #4: Secure Configuration of Enterprise Assets and Software
CSC #13: Network Monitoring and Defense

Axis devices feature a prevention mechanism to identify and block brute-force attacks coming from the network such as password-guessing. The feature, called brute-force delay protection, is available in AXIS OS 7.30 and later.

Brute-force delay protection is enabled by default starting from AXIS OS 11.5. For detailed configuration examples and recommendations, see Brute force delay protection in AXIS OS Knowledge base.

CSC #3: Data Protection

Axis devices use both volatile and non-volatile memory, and while the volatile memory is erased whenever you unplug the device from its power source, information stored in the non-volatile memory remains and is made available again at start-up. We avoid the common practice of simply removing the data pointers to make the stored data invisible to the file system, which is why a factory reset is required. For NAND-flash memory the UBI function Remove Volume is used, the equivalent function is used for eMMC-flash memory that signalizes that storage blocks are not used anymore. The storage controller then will wipe those storage blocks accordingly.

When decommissioning an Axis device, we recommend that you reset the device to factory default settings, which will erase any data stored on the device's non-volatile memory.

Note that issuing a factory default command will not immediately erase the data, instead the device will reboot and the data erasure will occur during system boot.  It is therefore not sufficient to merely issuing the factory default command, the device must also be allowed to reboot and complete its boot before being powered off to guarantee that the data erase has completed.

This table contains more information about data stored in the non-volatile memory.

* The signed firmware process uses custom certificates that allow users to upload (among other things) AXIS OS.
** Recordings and images stored on edge storage (SD card, network share) have to be deleted by the user separately. For more information, see Formatting Axis SD cards in AXIS OS Knowledge base.
*** All user-made configurations, from creating accounts to network, O3C, event, image, PTZ and system configurations.
**** The device retains any pre-installed applications but deletes all user-made configurations to them
***** Production data (calibration, 802.1AR production certificates) and lifetime statistics include non-sensitive and non-user-related information.

Basic hardening is the minimum recommended level of protection for Axis devices. The basic hardening topics are "configurable on the edge". This means that they can be directly configured in the Axis device without further dependencies to third-party network infrastructure, video, or evidence management systems (VMS, EMS), equipment or applications.

CSC #4: Secure Configuration of Enterprise Assets and Software

Before you configure your device, make sure that it’s in a factory default state. It's also important to reset the device to factory default settings when you need to clear it from user data or decommission it. For more information, see Decommissioning.

CSC #2: Inventory and Control of Software Assets

Patching software is an important aspect of cybersecurity. Attackers will often try to exploit commonly known vulnerabilities and may succeed if they gain network access to an unpatched service. Make sure you always use the latest AXIS OS since it may include security patches for known vulnerabilities. The release notes for a specific version may explicitly mention a critical security fix, but not all general fixes.

Axis maintains two types of AXIS OS tracks: the active track and the long-term support (LTS) tracks. While both types include the latest critical vulnerability patches, the LTS tracks do not include new features, as the aim is to minimize the risk of compatibility issues. For more information, see AXIS OS lifecycle in AXIS OS Information.

Axis provides a forecast for upcoming releases with information about important new features, bug fixes and security patches. To read more, see Upcoming releases in AXIS OS Information. Visit Firmware at axis.com to download AXIS OS for your device.

This chart illustrates the importance of keeping Axis devices up to date.

CSC #4: Secure Configuration of Enterprise Assets and Software
CSC #5: Account Management

The device root account is the main device administration account. Before you can use the root account, you need to set a device password. Make sure to use a strong password and limit the usage of the root account to administration tasks only. We do not recommend that you use the root account in daily production.

When operating Axis devices, using the same password simplifies management but increases your vulnerability to breaches and data leaks. Using unique passwords for each single Axis device provides high security but makes device management more complex. We recommend that you regularly change the password on your devices.

We recommend that you implement guidelines that require new passwords to be sufficiently long and complex, such as the NIST password recommendations. Axis devices support passwords up to 64 characters. Passwords shorter than 8 characters  are considered weak.

CSC #4: Secure Configuration of Enterprise Assets and Software
CSC #5: Account Management

The default root account has full privileges and should be reserved for administrative tasks. We recommend that you create a client user account with limited privileges for daily operation. This reduces the risk of compromising the device administrator password.

For more information, see the white paper Identity and access management in video surveillance systems.

CSC #5: Account Management

Axis devices have a web server that allows users to access the device via a standard web browser. The web interface is intended for configuration, maintenance, and troubleshooting. It’s not intended for daily operations, for example as a client to view video.

The only clients that should be allowed to interact with Axis devices during daily operations are video management systems (VMS) or device administration and management tools such as AXIS Device Manager. System users should never be allowed to access Axis devices directly. For more information, see Disable web interface access.

CSC #4: Secure Configuration of Enterprise Assets and Software

Starting from AXIS OS 9.50, it’s possible to disable the web interface of an Axis device. Once you deploy an Axis device into a system (or add it to AXIS Device Manager), we recommend that you remove the option for people within the organization to access the device via a web browser. This creates an additional layer of security if the device account password is shared within the organization. The safer option is to exclusively set up access to Axis devices through dedicated applications that offer advanced identity access management (IAM) architecture, more traceability, and safeguards to avoid account leakage.

CSC #12: Network Infrastructure Management

The device IP configuration depends on the network configuration, such as IPv4/IPv6, static or dynamic (DHCP) network address, subnet mask, and default router. We recommend that you review your network topology whenever you add new types of components.

We also recommend that you use static IP address configuration on your Axis devices to ensure network reachability and disentangle the dependency to servers in the network (such as DHCP servers) that might be a target for attacks.

CSC #8: Audit Log Management

From a security perspective, it’s important that you set the correct date and time. This ensures, for example, that system logs are correctly time-stamped and that digital certificates can be validated and used during runtime. Without proper time-sync, services that rely on digital certificates such as HTTPS, IEEE and 802.1x may not work correctly.

We recommend that you keep the Axis device clock synchronized with Network Time Protocol (NTP, unencrypted) servers or - preferably - Network Time Security (NTS, encrypted) servers. Network Time Security (NTS), an encrypted and secure variant of Network Time Protocol (NTP), was added in AXIS OS 11.1. We recommend that you configure multiple time servers for higher time-sync accuracy but also to account for a failover scenario where one of the configured time servers might be unavailable.

Using public NTP or NTS servers can be an alternative for individuals and small organizations that can’t facilitate local time server instances themselves. For more information about NTP/NTS in Axis devices, see NTP and NTS in AXIS OS Knowledge base.

CSC #3: Data Protection

SD card
If the Axis device supports and uses Secure Digital (SD) cards to store video recordings, we recommend that you apply encryption. This will prevent unauthorized individuals from being able to play the stored video from a removed SD card.

To learn more about SD card encryption in Axis devices, see SD card support in AXIS OS Knowledge base.

Network share (NAS)
If you use a Network Attached Storage (NAS) as a recording device, we recommend that you keep it in a locked area with limited access and enable hard disc encryption on it. Axis devices utilize SMB as network protocol for connecting to a NAS to store video recordings. While earlier versions of SMB (1.0 and 2.0) don’t provide any security or encryption, later versions (2.1 and later) do, which is why we recommend that you use later versions during production.

To learn more about proper SMB configuration when you connect an Axis device to a network share, see Network share in AXIS OS Knowledge base.

CSC #3: Data Protection

Starting from AXIS OS 10.10, Axis devices support encrypted export of edge recordings. We recommend that you use this feature as it prevents unauthorized individuals from being able to play exported video material.

CSC #4: Secure Configuration of Enterprise Assets and Software

You can upload applications onto the Axis device to extend its functionality. Many of them come with their own user interface for interacting with a certain feature. Applications may use security functionality that’s provided by AXIS OS.

Axis devices are preloaded with several applications developed by Axis according to the Axis security development model (ASDM). For more information about Axis applications, see Analytics at axis.com.

For third-party applications, we recommend that you contact the vendor for proof points regarding the security of the application in terms of operation and testing and if it has been developed according to common best-practice security development models. Vulnerabilities found in third-party applications must be reported to the third-party vendor directly.

We recommend that you only operate trusted applications and remove unused applications from Axis devices.

CSC #4: Secure Configuration of Enterprise Assets and Software

Even though unused services and functions are not an immediate security threat, it’s good practice to disable unused services and functions to reduce unnecessary risks. Keep reading to learn more about services and functions you can disable if they are not in use.

Starting from AXIS OS 11.2, devices with multiple network ports, such as AXIS S3008, come with the option to disable both the PoE and network traffic of their network ports. Leaving unused network ports unattended and active poses a severe security risk.

Discovery protocols, such as Bonjour, UPnP, ZeroConf, and WS-Discovery, are support services that make it easier to find the Axis device and its services on the network. After you have deployed the device and added it to the VMS, we recommend that you disable the discovery protocol to stop the Axis device from announcing its presence on the network.

* Functionality was removed from AXIS 10.12 and is not available in later versions

We recommend that you disable old, outdated, and insecure TLS versions before you put your Axis device in production. Outdated TLS versions are usually disabled by default, but it’s possible to enable them in Axis devices to provide backwards compatibility to third-party applications that haven’t yet implemented TLS 1.2 and TLS 1.3.

We recommend that you disable access to the script editor environment. The script editor is used for troubleshooting and debugging purposes only.

The script editor was removed from AXIS OS 10.11 and is not available in later versions.

By default, Axis devices announce their current Apache and OpenSSL versions during HTTP(S) connections with clients on the network. This information is useful when you use network security scanners on a regular basis since it provides a more detailed report of outstanding vulnerabilities in a particular AXIS OS version.

It’s possible to disable the HTTP(S) server headers to reduce information exposure during HTTP(S) connections. However, we only recommend that you disable the headers if you operate your device according to our recommendations and keep it up to date at all times.

The option to disable the HTTP(S) server headers is available starting from AXIS OS 10.6.

In Axis video surveillance-oriented products, such as the network cameras, audio in/out and microphone functionality are disabled by default. If you require audio capabilities, you must enable them before use. In Axis products where audio in/out and microphone functionality are key features, such as in Axis intercoms and network speakers, audio capabilities are enabled by default.

We recommend that you disable audio capabilities if you don’t use them.

Axis devices usually have support for at least one SD card to provide local edge storage of video recordings. We recommend that you disable the SD card slot entirely if you don’t use SD cards. The option to disable the SD card slot is available from AXIS OS 9.80

For more information, see Disabling the SD card in AXIS OS Knowledge base.

FTP is an insecure communication protocol used for troubleshooting and debugging purposes only. FTP access was removed from AXIS OS 11.1 and is not available in later versions. We recommend that you disable FTP access and use secure SSH access for troubleshooting purposes.

For more information about SSH, see SSH access in AXIS OS Portal. For information about debugging options using FTP, see FTP access in AXIS OS Portal.

SSH is a secure communication protocol used for troubleshooting and debugging purposes only. It’s supported by Axis devices starting from AXIS OS 5.50. We recommend that you disable SSH access.

For more information about debugging options using SSH, see SSH access in AXIS OS Knowledge base.

Telnet is an insecure communication protocol used for troubleshooting and debugging purposes only. It’s supported by Axis devices with earlier versions than AXIS OS 5.50. We recommend that you disable Telnet access.

ARP/Ping was a method for setting the Axis device’s IP address using tools like AXIS IP Utility. The functionality was removed from AXIS OS 7.10 and is not available in later versions. We recommend that you disable the feature in Axis devices with AXIS OS 7.10 and earlier versions.

CSC #1: Inventory and Control of Enterprise Assets
CSC #4: Secure Configuration of Enterprise Assets and Software
CSC #13: Network Monitoring and Defense

IP address filtering prevents unauthorized clients from accessing the Axis device. We recommend that you configure your device to either allow the IP addresses of authorized network hosts or to deny the IP addresses of unauthorized network hosts.

If you choose to allow IP addresses, make sure to add all authorized clients (VMS server and administrative clients) to your list.

CSC #3: Data Protection

HTTP and HTTPS are enabled by default in Axis devices starting from AXIS OS 7.20. While HTTP access is insecure with no encryption at all, HTTPS encrypts the traffic between the client and the Axis device. We recommend that you use HTTPS for all administrative tasks on the Axis device.

For configuration instructions, see HTTPS only and HTTPS ciphers.

We recommend that you configure your Axis device to use HTTPS only (with no HTTP access possible). This will automatically enable HSTS (HTTP Strict Transport Security), which will improve the security of the device further.

Starting from AXIS OS 7.20, Axis devices come with a self-signed certificate. While a self-signed certificate isn’t trusted by design, it’s adequate to securely access the Axis device during initial configuration and when there’s no public key infrastructure (PKI) available. If available, the self-signed certificate should be removed and replaced with proper signed client certificates issued by a PKI authority of choice. Starting from AXIS OS 10.10, the self-signed certificate was replaced by the IEEE 802.1AR secure device ID certificate.

Axis devices support and use TLS 1.2 and TLS 1.3 cipher suites to securely encrypt HTTPS connections. The specific TLS version and cipher suite used depends on the client that connects to the Axis device and will be negotiated accordingly. After you reset the Axis device to factory default settings, it’s possible that the cipher list may update automatically according to the latest available best-practice configuration provided by Axis.

For reference and transparency, use the secure and strong cipher suites listed in TLS 1.2 and lower and TLS 1.3.

ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384

By default, only strong cipher suites according to the TLS 1.3 specifications are available:

TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384

These suites can’t be configured by the user.

CSC #1: Inventory and Control of Enterprise Assets
CSC #8: Audit Log Management

The access log provides detailed logs of users accessing the Axis device, which makes both audits and access control management easier. We recommend that you enable this feature and combine it with a remote syslog server so that the Axis device can send its logs to a central logging environment. This simplifies the storage of log messages and their retention time.

For more information, see Device access logging in AXIS OS Knowledge base.

CSC #1: Inventory and Control of Enterprise Assets
CSC #12: Network Infrastructure Management

Axis offers physical intrusion and/or tampering switches as optional accessories to enhance the physical protection of Axis devices. These switches can trigger an alarm which makes it possible for Axis devices to send a notification or an alarm to selected clients.

For more information about available anti-tampering accessories, see:

• AXIS TA8501 Physical Tampering Switch

• AXIS Dome Intrusion Switch C

• AXIS Door Switch A

The instructions for extended hardening build on the hardening topics described in Default protection and Basic hardening. But while you can apply the default and basic hardening instructions directly on your Axis device, the extended hardening requires active participation by the entire vendor supply chain, the end-user organization, and the underlying IT- and/or network infrastructure.

CSC #12: Network Infrastructure Management

We don’t recommend that you expose the Axis device as a public web server, or that you in any other way give unknown clients network access to the device. For small organizations and individuals that don’t operate a VMS or need to access video from remote locations, we recommend using AXIS Companion.

AXIS Companion employs Windows/iOS/Android client software, is free of charge, and provides an easy way to access video securely without exposing the Axis device to the Internet. For more information about AXIS Companion, see axis.com/companion.

CSC #12: Network Infrastructure Management

A common way to reduce the risks of network exposure is to physically and virtually isolate network devices and related infrastructure and applications. Examples of such infrastructure and applications are video management software (VMS), network video recorders (NVR), and other types of surveillance equipment.

We recommend that you isolate your Axis devices and related infrastructure and applications on a local network that isn’t connected to your production and business network.

To apply basic hardening, protect the local network and its infrastructure (router, switches) from unauthorized access by adding a multilayer of network-security mechanisms. Examples of such mechanisms are VLAN segmenting, limited routing capabilities, virtual private network (VPN) for site-to-site or WAN access, network layer 2/3 firewalling, and access control lists (ACL).

To extend the basic hardening, we recommend that you apply more advanced network inspection techniques, such as deep packet inspection and intrusion detection. This will add consistent and comprehensive threat protection within the network. Extended network hardening requires dedicated software and/or hardware appliances.

CSC #1: Inventory and Control of Enterprise Assets
CSC #12: Network Infrastructure Management

You can use network security scanners to perform vulnerability assessments of your network devices. The purpose of a vulnerability assessment is to provide a systematic review of potential security vulnerabilities and misconfigurations.

We recommend that you perform regular vulnerability assessments of your Axis devices and their related infrastructure. Before you start the scan, make sure that your Axis devices have been updated to the latest available AXIS OS version, either on the LTS or active track.

We also recommend that you review the scanning report and filter out known false positives for Axis devices, which you can find in the AXIS OS Vulnerability Scanner Guide. Submit the report and any additional remarks in a helpdesk ticket to Axis support on axis.com.

CSC #3: Data Protection
CSC #12: Network Infrastructure Management

We recommend that you deploy web server and client certificates to your Axis devices that are trusted and signed by a public or private certificate authority (CA). A CA-signed certificate with a validated trust chain helps to remove browser certificate warnings when you connect over HTTPS. A CA-signed certificate also ensures the authenticity of the Axis device when you deploy a network access control (NAC) solution. This mitigates the risk of attacks from a computer impersonating an Axis device.

You can use AXIS Device Manager, which comes with a built-in CA service, to issue signed certificates to Axis devices.

CSC #6: Access Control Management
CSC #13: Network Monitoring and Defense

Axis devices support IEEE 802.1X port-based network access control through the EAP-TLS method. For optimal protection, we recommend that you use client certificates signed by a trusted certificate authority (CA) when you authenticate your Axis device.

CSC #3: Data Protection
CSC #6: Access Control Management

Axis devices support 802.1AE MACsec which is a well-defined network protocol that cryptographically secures point-to-point ethernet links on network layer 2 ensuring the confidentiality and integrity of data transmissions between two hosts. As MACsec operates at the low layer 2 of the network stack, it adds an additional layer of security to network protocols that do not offer native encryption capabilities (ARP, NTP, DHCP, LLDP, CDP…) as well as ones that do offer it alike (HTTPS, TLS).

The IEEE 802.1AE MACsec standard describes two modes of operation, a manually configurable Pre-Shared Key (PSK)/Static CAK mode and an automatic Master Session/Dynamic CAK mode using IEEE 802.1X EAP-TLS sessions.  Axis device supports both two modes.

For more information about 802.1AE MACsec and how to configure it in AXIS OS devices, see IEEE 802.1AE in the AXIS OS knowledge base.

CSC #1: Inventory and Control of Enterprise Assets
CSC #13: Network Monitoring and Defense

Axis devices with Axis Edge Vault support the network standard IEEE 802.1AR. This allows for automated and secure onboarding of Axis devices into the network through Axis device ID, a unique certificate installed in the device during production. For an example of secure device onboarding, please read more in Secure integration of Axis devices into Aruba networks.

For more information, see the white paper Axis Edge Vault. To download the Axis Device ID certificate chain, which is used to validate the device identity of Axis devices, see the Public Key Infrastructure Repository on axis.com.

CSC #8: Audit Log Management

Axis devices support the following SNMP protocols:

• SNMP v1: supported for legacy reasons only, do not use.

• SNMP v2c: can be used on a protected network segment.

• SNMP v3: recommended for monitoring purposes.

Axis devices also support monitoring MIB-II and AXIS Video MIB. To download AXIS Video MIB, see AXIS Video MIB in AXIS OS Knowledge base.

To learn more about how you configure SNMP in AXIS OS, see SNMP (Simple Network Management Protocol) in AXIS OS Knowledge base.

CSC #8: Audit Log Management

You can configure an Axis device to send all its log messages encrypted to a central syslog server. This makes audits easier and prevents log messages from being deleted in the Axis device, either intentionally/maliciously or unintentionally. Depending on company policies, it can also provide extended retention time of device logs.

For more information about how you enable the remote syslog server in different AXIS OS versions, see Syslog in AXIS OS Knowledge base.

CSC #3: Data Protection

Starting from AXIS OS 7.40, Axis devices support secure video streaming over RTP, also referred to as SRTP/RTSPS. SRTP/RTSPS uses a secure end-to-end encrypted transportation method to make sure that only authorized clients receive the video stream from the Axis device. We recommend that you enable SRTP/RTSPS if your video management system (VMS) supports it. If available, use SRTP instead of unencrypted RTP video streaming.

CSC #3: Data Protection

Starting from AXIS OS 10.11, Axis devices with Axis Edge Vault support signed video. With signed video, Axis devices can add a signature to their video stream to make sure the video is intact and to verify its origin by tracing it back to the device that produced it. The video management system (VMS) or evidence management system (EMS) can also verify the authenticity of the video provided by an Axis device.

For more information, see the white paper Axis Edge Vault. To find the Axis root certificates used to validate the signed video authenticity, see Device access in AXIS OS Knowledge base.

The quickstart guide provides a brief overview of settings you should configure when you harden Axis devices with AXIS OS 5.51 and later versions. It covers the hardening topics you can read about in Basic hardening, however, it doesn’t cover the topics in Extended hardening since they require extensive and customer-specific configuration on a case-by-case basis.

We recommend that you use AXIS Device Manager to harden multiple Axis devices in a quick and cost-efficient way. If you need to use another application for device configuration, or only need to harden a few Axis devices, we recommend that you use the VAPIX API.

Internet-exposed devices
CSC #12: Network Infrastructure Management

We don’t recommend that you expose the Axis device as a public web server or that you in any other way give unknown clients network access to the device. For more information, see Limit internet exposure.

Common password
CSC #4: Secure Configuration of Enterprise Assets and Software
CSC #5: Account Management

We strongly advise you to use a unique password for each device instead of a generic password for all devices. For instructions, see Set device root password and Create dedicated accounts.

Anonymous access
CSC #4: Secure Configuration of Enterprise Assets and Software
CSC #5: Account Management.

We don’t recommend that you allow anonymous users to access video and configuration settings in the device without having to provide login credentials. For more information, see Credentialed access.

Secure communication disabled
CSC #3: Data Protection

We don’t recommend that you operate the device using insecure communication and access methods, such as HTTP or basic authentication where passwords are transferred without encryption. For more information, see HTTPS enabled. For configuration recommendations, see Digest authentication.

Outdated AXIS OS version
CSC #2: Inventory and Control of Software Assets

We strongly advise you to operate the Axis device using the latest available AXIS OS version, either on the LTS or active track. Both tracks provide the latest security patches and bug fixes. For more information, see Upgrade to latest AXIS OS.

You can use the VAPIX API to harden your Axis devices based on the topics covered in Basic hardening. In this table, you can find all basic hardening configuration settings regardless of the AXIS OS version of your Axis device.

It’s possible that some configuration settings are no longer available in your device’s AXIS OS version since some functionality has been removed over time to increase security. If you receive an error when you issue the VAPIX call, it could be an indication that the functionality is no longer available in the AXIS OS version.

* Replace "X" with the actual port number in "port=X". Examples: "port=1" will disable port 1 and "port=2" will disable port 2.
** Replace "1" with the actual port number in "eth1.1". Examples: "eth1.1" will disable port 1 and "eth1.2" will disable port 2.
*** After 20 failed login attempts within one second, the client IP address is blocked for 10 seconds. Every following failed request within the 30 seconds page interval will result in the DoS blocking period being extended by another 10 seconds.

You can use AXIS Device Manager and AXIS Device Manager Extend to harden your Axis devices based on the topics covered in Basic hardening. Use this configuration file, which consists of the same configuration settings listed in Basic hardening via VAPIX API.

It’s possible that some configuration settings are no longer available in your device’s AXIS OS version since some functionality has been removed over time to increase security. AXIS Device Manager and AXIS Device Manager Extend will automatically remove these settings from the hardening configuration.