Feature list (24.06)

Details
Release version	v24.06
Release Date	05 Jun 2024
Published	05 Jun 2024
Updated	02 Jul 2024

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	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.
Device administration	Control of registration methods	System admin users 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	Device policies	Settings that govern behaviour by (or local to) an endpoint/device can be set centrally in the console and promulgated, to be consumed by devices in the wider estate.
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 the 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 functionaliity [optionally] restricts devices ability to negotiate keys with one another. When anabled, 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 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 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 key negotiation	Bilocation key controls	System administrators can control the length of time bilocation and p2p keys are valid for within their tenant.
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 MQTT, as specified by the client application.
Device metadata	'Application Name'	Declaration of an ‘Application Name’ at registration. When declared, this field will display in the console.
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 monitoring	Device details - Heartbeat	Devices can send a ‘heartbeat’ message to the 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/Active - a heartbeat message has been received in the 5 minutes prior to page load. Amber/Recently active - a heartbeat message has been received between 5-10 minutes prior to page load. Red/Inactive - 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.
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 registration	Device registration	Devices can register under control of an authorised user.
Device registration	Device deregistration	Devices can de-register under control of an authorised user.
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	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	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.
User administration	RBAC	Grouping of system administration permissions into roles: -‘QuantumCloud 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 -‘QuantumCloud 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).