Feature list (25.09)

Details
Release version	v25.09.2
Release Date	22 Oct 2025
Published	22 Oct 2025

Category	Name	Description
Activity/audit	Audit events	All events related to devices or users are captured and displayed in the ‘Activity’ page in the console.
Activity/audit	Audit export API	Customers can optionally expose an API that allows customers’ system administrators and security managers can pull audit logs from the platform via the Audit export API.
Activity/audit	Event filtering	Console users can perform a basic filter on Activity events to identify those related to a particular user or device, or events with specific text in the description/fields.
Compliance	FIPS	Platform supports running in FIPS mode (provided the underlying OS is in FIPS mode). The platform uses BC-FJA (Bouncy Castle FIPS Java API) module in FIPS mode (FIPS Inside: #4743).
Data Persistence	Database deployment options	The Platform can be configured to persist data in an internal database (SKA-EC only) or must be configured to store its data in an external customer managed database (SKA-CC) - PostgreSQL is currently supported.
Device administration	Control of registration methods	System administrators can customise which registration methods can be used for their tenant by editing the ‘Default registration policy’ in the admin console. The policy restricts the methods by which devices can register to those selected. Users can select any combination of methods (including none, which will prevent all devices from joining the tenant). Supported methods are: -Q-Key; -OTA TLS; and -OTA Quantum.
Device administration	Organisational Units	System administrators can organise their devices by grouping them into ‘Organisational Units’ (OUs). OUs exist in a structured hierarchy and can be created/edited, moved around in the hierarchy, as well as deleted. Device behaviour is governed by the policies linked to specific OUs. Where OUs do not have a specific instance of a policy, they will inherit it from their parent OU (or the root OU if none are specified in the hierarchy). Policy exceptions can also be applied to specific devices within an OU.
Device administration	Policy assignment	Instances of policies can be created, edited and applied to OUs or devices as desired. Policies drive device behaviour (options, settings, etc.) so policy application drives whether groups of devices act similarly or differently.
Device administration	Quarantine devices	Devices can be placed in a ‘Quarantined’ state, which prevents them from being able to negotiate new Bilocation keys. All other attributes of the device will remain unchanged - (quarantined devices will be able to maintain connection and authenticate with SKA (Platform) and all other settings will be retained).
Device administration	Policy archive	Policy instances can be removed from view.
Device administration	Device deregistration	Devices can be be deregistered manually via the console.
Device administration	Security Groups	Security Group functionality [optionally] restricts devices ability to negotiate keys with one another. When enabled, devices must be members of at least one mutual Security Group in order to negotiate keys with one another. This allows system administrators to actively restrict key-forming within a tenant (Allow/Deny), if they so wish. -Security group enforcement can be switched on and off for the tenant. -Security Groups can be created, edited and deleted. -Devices can be assigned to/unassigned from Security Groups.
Device administration	Authentication Key controls	System administrators can can control the length of time device authentication keys are valid for within their tenant. After this time period, devices will need to re-authenticate in order to access any SKA (Platform) services.
Device administration	Device recovery	System administrators can reset device back to ‘Registered’ provisioning state, meaning the device will be de-provisioned, but not de-registered. The device will retain all other associations (Organisational Unit, Policies, Security Groups, etc.). (This is dependent on the functionality being built into the application/service.)
Device administration	Device details - Properties	Devices can scrape information about their environment, add it to any other relevant information and send it to SKA (Platform). This information can be viewed in the ‘Device details’ panel on the console.
Device administration	Device policies	Settings that govern behaviour by (or local to) an endpoint/device can be set centrally in the platform console and promulgated, to be consumed by devices in the wider estate.
Device key negotiation	Key negotiation via sockets	Devices can negotiate keys with other devices using a socket specified by the client application.
Device key negotiation	Key negotiation via MQTT	Devices can negotiate keys with other devices using a MQTT, as specified by the client application.
Device key negotiation	Bilocation key controls	System administrators can control the length of time bilocation and p2p keys are valid for within their tenant.
Device metadata	'Application Name'	Declaration of an ‘Application Name’ at registration.
Device metadata	Registration configuration	System administrators can define a specific OU they want a device to go to at point of registration. (This is dependent on the functionality being built into the application/service.)
Device registration	Q-Key	Registration using a manually provisioned ‘Q-Key’. This method is considered quantum safe, provided organisational protocols for security of a pre-shared key are followed.
Device registration	Device registration	Devices can register under control of an authorised user.
Device registration	Device de-registration	Devices can de-register under control of an authorised user.
Device registration	OTA TLS	Registration ‘over-the air’ using TLS handshake - this method is not considered Quantum-safe and as such is only suitable for provisioning in e.g. test or lab environments, or other scenarios where quantum-safety is not required.
Device registration	OTA Quantum	Registration ‘over-the-air’ using a combination of three key encapsulation mechanisms that are quantum-resistant (i.e. part of the NIST Post-Quantum Cryptography Standardization Project). This method is considered quantum safe, provided at least one of these algorithms continues to be so. The methods used are: -CRYSTALS Kyber -FrodoKEM -Classic McEliece
User administration	Create new users	New users can be created and invited to use the system.
User administration	RBAC	Grouping of system administration permissions into roles: -‘SKA (Platform) User’ – view only user (has view only-access to all pages and no edit rights); -‘Commissioning Engineer’ intended for those users commissioning devices onto a network and checking devices are correctly registered, but where such users are not required to modify policies or hierarchy in which a device sits (as ‘SKA (Platform) User’, but can also register and de-register devices); -‘SDK user’ – intended for application developers to have full functionality in test environments or environments where programming and requirements are highly fluid (as ‘Commissioning Engineer’, with additional rights to create and edit Organisational Units (see below), Policies and associated linking rights); and -‘System administrator’ – users with all rights to the customers’ tenant (as SDK user, with user administrative rights (change roles, edit user details).
User administration	Edit/ delete users	Users details and roles can be edited and users can be deleted.
User administration	MFA login	Customers can request time-based one time passcode (TOTP) to be required when logging in to the console.
Device monitoring	Device details - Properties	Devices can scrape information about their environment, add it to any other relevant information and send it to the platform. This information can be viewed in the ‘Device details’ panel on the console.
Device monitoring	Device details - Heartbeat	Devices can send a ‘heartbeat’ message to SKA (Platform), so the activity status of the application can be inferred and viewed in the ‘Device details’ panel on the console. Devices may be: -Green/Healthy - a heartbeat message has been received in the 5 minutes prior to page load. -Amber/Warning - a heartbeat message has been received between 5-10 minutes prior to page load. -Red/Unresponsive - no heartbeat message has been received for more than 10 minutes prior to page load. -Grey/Unknown - no heartbeat message has ever been received for this device. *These values are the defaults. The boundaries can be customised (see ‘Customised heartbeat status boundaries’).
Device monitoring	Customised heartbeat status boundaries	System administrators can customise the time boundaries between the Activity statuses (devices being considered Green/Active, Amber/Recently active and Red/Inactive). Additional policies can be created and applied at OU level or to individual devices for more granular control.
Resiliency	HA	The platforms supports running in an active/passive high availability setup (2 nodes with a load balancer). TPM HA as a RoT is supported for HA SKA-CC deployments (Ubuntu 24.04 LTS only).
Instance management	License registration	Each instance must be individually licensed with a License file supplied by Arqit. SKA-EC - single tenant license SKA-CC - multi-tenant license
Security	Root Of Trust (RoT)	Platform administrators have multiple options available to securely store the Platform Master Key (PMK) which is the RoT for the platform. The PMK can be stored in an external HSM or can be protected by a TPM available on the platform host (virtual or physical TPMs). Additionally, customers have the option to deploy the platform without a hardware root of trust, which relies on a basic XOR operation instead of a key wrapping operation using a PMK. This is less secure than using a customer provided PMK as the root of trust which is stored in external hardware with enterprise grade encryption such as an HSM or TPM, but reduces deployment complexity.