u-blox SARA-R4, SARA-R5 Instruction manual
lease
blox cellular
IoT Security-as-a-Service
SARA-R4 / SARA-R5
Application Note
Abstract:
Technical data sheet describing the IoT Security-as-a-Service value proposition for umodule series SARA-R4 and SARA-R5.
UBX-20013561 - R06
C1-Public www.u-blox.com
IoT Security-as-a-Service - Application Note
Prototype
Objective specification
Target values. Revised and supplementary data will be published later.
Advance information
Data based on early testing. Revised and supplementary data will be published later.
Early production information
Data from product verification. Revised and supplementary data may be published later.
u-blox or third parties may hold intellectual property rights in the products, names, logos and designs included in this document.
Copying, reproduction, modification or disclosure to third parties of this document or any part thereof is only permitted with the
express written permission of u
The information contained herein is provided “as is” and u
. No warranty, either express or
implied, is given, including but not limited
s, reliability and fitness for a particular
purpose of the information. This document may be revised by u
most recent documents,
visit www.u
Copyright © u
Document information
Title IoT Security-as-a-Service
Subtitle SARA-R4 / SARA-R5
Document type Application Note
Document number UBX-20013561
Revision and date R06 05-11-2020
Disclosure restriction
C1-Public
Product status
Functional Sample
In development /
Engineering sample
Initial production
Mass production /
End of life
Corresponding content status
Draft For functional testing. Revised and supplementary data will be published later.
Production information Document contains the final product specification.
This document applies to the following products:
Product name
SARA-R4 series
SARA-R5 series
"63" / "73" /”83B” product versions
All product versions
UBX-20013561 - R06 Document information Page 2 of 53
C1-Public
-blox.com.
-blox AG.
-blox.
-blox assumes no liability for its use
to, with respect to the accuracy, correctnes
-blox at any time without notice. For the
IoT Security-as-a-Service - Application Note
Contents
Document information ................................................................................................................................ 2
Contents .......................................................................................................................................................... 3
1 Introduction ............................................................................................................................................. 5
1.1 Important note ............................................................................................................................................ 5
1.2 Scope ............................................................................................................................................................. 5
2 Security ..................................................................................................................................................... 6
2.1 Overview ........................................................................................................................................................ 6
2.2 Foundations of u-blox security ................................................................................................................. 6
2.2.1 Secure boot .......................................................................................................................................... 7
2.2.2 Secure updates ................................................................................................................................... 7
2.2.3 Secure production .............................................................................................................................. 7
2.2.4 Root of trust ......................................................................................................................................... 7
3 Services APIs ........................................................................................................................................... 9
3.1 REST APIs security ..................................................................................................................................... 9
3.2 Accessing the REST APIs .......................................................................................................................... 9
3.3 How to access the u-blox IoT Security-as-a-Service when using a private network ...................10
4 Claim ownership .................................................................................................................................. 11
4.1 Automatic enrollment ..............................................................................................................................11
4.1.1 Change the ownership .....................................................................................................................13
4.2 Bootstrap and device assignment to the owner procedure .............................................................13
4.3 Two stage bootstraps ..............................................................................................................................14
4.4 Security heartbeat ....................................................................................................................................14
4.5 Feature provisioning .................................................................................................................................16
4.5.1 Service provisioning .........................................................................................................................16
4.6 Anti-cloning detection and rejection .....................................................................................................17
5 Design security .................................................................................................................................... 18
5.1 Local C2C (Chip-to-Chip) Security .........................................................................................................18
5.1.1 C2C encapsulation and encryption protocol ...............................................................................19
5.1.2 Local C2C key pairing .......................................................................................................................20
5.1.3 Local C2C usage (Open secure session) ......................................................................................23
5.1.4 Local C2C usage (Close secure session) ......................................................................................25
5.1.5 Local C2C Rekeying ..........................................................................................................................26
5.1.6 Local C2C use-case ..........................................................................................................................26
5.2 Local data protection ...............................................................................................................................27
5.2.1 Use case ..............................................................................................................................................28
6 E2E Security ......................................................................................................................................... 29
6.1 E2E Symmetric KMS ................................................................................................................................29
6.1.1 Use case ..............................................................................................................................................31
6.2 End-to-end data protection ....................................................................................................................36
6.2.1 Upstream (device to cloud) .............................................................................................................37
6.2.2 Downstream (cloud to device) ........................................................................................................38
6.2.3 Use case ..............................................................................................................................................39
6.3 TLS version .................................................................................................................................................42
UBX-20013561 - R06 Contents Page 3 of 53
C1-Public
IoT Security-as-a-Service - Application Note
6.4 DTLS version ..............................................................................................................................................42
7 Access control ..................................................................................................................................... 43
7.1 Zero Touch Provisioning ..........................................................................................................................43
7.1.1 Service registration ..........................................................................................................................43
7.1.2 Certificate provisioning ...................................................................................................................44
7.1.3 Just in time provisioning .................................................................................................................45
7.1.4 Device registration ...........................................................................................................................46
7.1.5 Use case (ZTP for Amazon Web Services) ..................................................................................46
Appendix ....................................................................................................................................................... 51
A Glossary ................................................................................................................................................. 51
Related documents ................................................................................................................................... 52
Revision history .......................................................................................................................................... 52
Contact .......................................................................................................................................................... 53
UBX-20013561 - R06 Contents Page 4 of 53
C1-Public
IoT Security-as-a-Service - Application Note
1 Introduction
1.1 Important note
⚠ To be read before reviewing any other part of this document
The main aspect of this document is to detail the exciting opportunities that customers will have to
manage and organize the services and firmware on their own devices. However, this functionality
cannot be utilized if the ownership of each device has not been correctly claimed by the customer.
Ownership can only be achieved by sealing a valid DeviceProfileUID into the customer’s devices.
DeviceProfileUID can be autonomously generated accessing to the personal account in the u-blox
Thingstream service management console. Moreover, in order to be authorized to use the IoT
Security-as-a-Service APIs you need to generate the access key and secret through the management
console.
☞ Before reading this document, look at the Getting started guide to have an overview about all the
initial steps required
The ownership process is described in more detail in section 4 below.
1.2 Scope
This document describes what is defined by the term “Security” and how it is implemented in u-blox
cellular modules. In the document, “security services” indicates IoT Security-as-a-Service solutions.
Section 2 provides an overview of security and its strengths and details about foundation security as
the base for all security services.
Section 3 provides details about the u-blox services APIs.
Section 4 describes claim ownership process.
Section 5 describes Design security.
Section 6 describes End-to-End security.
Section 7 describes Zero Touch Provisioning (ZTP).
UBX-20013561 - R06 Introduction Page 5 of 53
C1-Public
IoT Security-as-a-Service - Application Note
2 Security
2.1 Overview
For today’s cloud-based information technology environment, it is vital to secure all data from
unauthorized or fraudulent access. For IoT devices the security of data is vital to protect both
businesses and the individual user / person.
For example:
• In connected retail a POS terminal must protect revenue flow from fraud by:
o Securely controlling access to the payment terminal.
o By providing payment data to authorized parties only.
• In asset tracking the data must be authenticated to the correct device to ensure the integrity of
the business process and its control.
• In order to protect recurring service revenues, smart devices in buildings must ensure that only
authorized technicians can remotely access and troubleshoot building management functions.
IoT devices connect physical objects to provide data traffic and access to networks – however the
physical objects (i.e. medical devices, controls, utility meters, vehicles, etc.) and the network of things
must also be secured. A weak element in IoT security (also known as a defect or vulnerability) may
ultimately also become a safety issue.
The u-blox device security implementation is designed to entirely remove these weak elements and
prevent the unauthorized or fraudulent access to the underlying data.
The following definitions will help in understanding the fundamentals of security:
• Integrity ensures that pieces of data have not been altered from a reference or controlled version.
• Authentication ensures that a given entity (with which the user is interacting) is the expected one.
• Authenticity is a special type of integrity, where the reference or controlled version is defined as
exactly the state of the data when it was under the control of a specific entity.
• Confidentiality means that no unauthorized access to the data is allowed (that is, encryption or
cryptography will be used).
2.2 Foundations of u-blox security
The strengths of the u-blox security service include the following:
• Unique device identity: An immutable chip ID together with a robust root of trust provide the
foundational security.
• Secure boot sequence and update processes: Only authenticated and authorized firmware and
updates can run on the device.
• Hardware-backed crypto functions: A secure client library generates the keys and cryptographic
functions to securely connect to the cloud.
• Root of trust-based authentication: Using the protected root of trust and unique session keys
ensures the integrity and confidentiality of both the communications and the data-at-rest (i.e.
inactive data that is stored physically in any digital form).
The following features maintain the integrity of the device over its entire lifecycle.
UBX-20013561 - R06 Security Page 6 of 53
C1-Public
IoT Security-as-a-Service - Application Note
2.2.1 Secure boot
Secure boot maintains the integrity of the code running on the module to ensure the device only runs
trusted software issued by an authorized manufacturer.
Because the authenticity and integrity of the software is secured, the module is suitable to be used in
mission critical solutions and enables highly secured devices.
2.2.2 Secure updates
Secure updates performed via FOTA or uFOTA (see the FW update application note [5]) allow the
customer’s chosen FOTA platform to remotely and securely update the module’s firmware. Updates
are signed by u-blox and verified before being applied. The resulting updated firmware is then
authenticated in the module via the secure boot process.
uFOTA is a comprehensive end-to-end u-blox FOTA service that allows customers control of the
process for remotely updating the module’s firmware “over-the-air”. This process utilizes the
additional security provided between the module and the service via PSK provisioning.
uFOTA enables the updating of the module firmware at no extra data overhead and cost of
implementing such services and processes, since they are implemented by u-blox.
☞ Customer permission is always required before any updates are performed.
2.2.3 Secure production
Secure production is undertaken with a significant emphasis on security, using well designed
processes and methods. The root of trust (RoT) is securely provisioned with personalization data
(using several keys). The personalization data is delivered using multiple layers of encryption to
protect it during the end-to-end process. Each layer of encryption is only retrieved at the correct stage
in the process, with the final layer only being retrieved within the module RoT itself.
As mentioned, the benefit for customers is that the module can be used in mission critical solutions
and enables highly secured devices.
☞ u-blox provisions secrets into each SARA-R4 module during the production process.
SARA-R5 products integrate a secure element in which secrets are provisioned by the secure element
chip manufacturer before the u-blox production process.
2.2.4 Root of trust
The root of trust (RoT) can always be trusted within a cryptographic system by providing a
comprehensive set of advanced security tools including:
• The secure execution of user applications.
• Tamper detection and protection.
• Secure storage and handling of keys and security assets.
• Resistance to side-channel attacks.
In SARA-R4 products the RoT is implemented in a trusted execution environment (TEE) and is a
critical component of the system.
A TEE is a secure area inside the main processor (trusted OS area), which is physically separated from
the rich OS (rich execution environment, REE) where applications are running. It protects the
confidentiality and integrity of the code and the data loaded into the TEE. It provides an excellent level
of robustness that is sufficient for the majority of IoT applications. A RoT implemented in the TEE
provides a better level of robustness compared to classic systems, which only implement security in
the REE.
UBX-20013561 - R06 Security Page 7 of 53
C1-Public
IoT Security-as-a-Service - Application Note
In SARA-R5 products the RoT is integrated in a secure element (SE).
A secure element is a dedicated microprocessor chip which stores sensitive data and runs secure
applications. It acts as a vault, protecting what’s inside the SE (applications and data) from malware
attacks that are typical in the host (i.e., the device operating system). This secure element is Common
Criteria certified EAL5+ and it allows to have eUICC on SARA-R5 since the GSMA and mobile network
operators require at least EAL4 to host an eSIM.
☞ SARA-R4 "63B", “73B”,”83B” product versions implement the RoT in the TEE.
☞ SARA-R5 products implement the RoT in the SE.
Figure 1: Security robustness levels
The IoT device is secured using the following steps:
• Provision trust – insert the root of trust at production: An immutable chip ID and the
hardware-based root of trust inserted during the production process provide the foundational
security and a unique device identity.
• Leverage trust – derive the trusted keys: Secure libraries and hardware-supported crypto
functions allow the generation of keys that securely connect the device to the cloud.
• Guarantee trust – use secure keys to secure any function: Secure keys ensure the authenticity,
integrity, and confidentiality to maintain control of the device and the data.
UBX-20013561 - R06 Security Page 8 of 53
C1-Public
IoT Security-as-a-Service - Application Note
3 Services APIs
The u-blox IoT Security-as-a-Service APIs provide cloud services to customers from where they can
access and manage the security features and processes for their devices, along with any other
functionality described in this document.
The REST APIs are defined and fully documented in the separate on-line documentation available at
“https://api.services.u-blox.com”. The swagger (YAML) specification file can be downloaded from the
same webpage.
If not yet done, we strongly recommend users to read the Getting started guide
3.1 REST APIs security
The APIs are secured using an API key and secret which can be generated on the u-blox Thingstream
services portal. The secret is used to generate an authorization header, which is used to authorize the
requests made to u-blox (see sections 6.1.1 and 6.2.3).
For further details on how to generate the authorization header, see the swagger documentation at
https://api.services.u-blox.com.
3.2 Accessing the REST APIs
To manage the IoT Security-as-a-Service, customers must first subscribe to an account for the u-blox
Thingstream, which is the service and account management platform for IoT Security-as-a-Service.
You can select between
• Basic account: an IoT Security-as-a-Service free-of-charge account restricted to up to ten active
devices
• Enterprise or Pro account: for more than 10 active devices; this is required to enable the
commercial version and to access to advanced features
Once access to the APIs has been granted, the customer will be able to view and manage the IoT
Security-as-a-Service attributes on their devices.
The APIs can be used to manage the following:
• Claim of ownership of individual devices as part of the bootstrap process (see section 4)
• Service provisioning and IoT Security-as-a-Service management functionality (see section 4.5)
including the management of:
o Individual devices
o The security services that are enabled / disabled on each device
o The device profiles used to identify devices and owners
o The process to organize global updates of multiple devices to enable or disable the security
services on them
The Sequence diagram in Figure 2 shows the API access process including:
• Customer onboarding
• Service account creation
• API key and secret retrieval
• Refresh Auth token
• Call APIs
UBX-20013561 - R06 Services APIs Page 9 of 53
C1-Public
IoT Security-as-a-Service - Application Note
Figure 2: API access processes
3.3 How to access the u-blox IoT Security-as-a-Service when
using a private network
To ensure the security services processes will work, customers using a private network (private APN)
must first check that their devices can reach the u-blox security service.
In particular, check that the module is able to connect to the domain icpp.services.u-blox.com.
If the module cannot reach the domain icpp.services.u-blox.com, the IPv4/IPv6 addresses may need
to be whitelisted on the private APN server in order to allow the connection to be made.
UBX-20013561 - R06 Services APIs Page 10 of 53
C1-Public
IoT Security-as-a-Service - Application Note
AT+USECDEVINFO="DeviceProfileUID","serial"
OK
u-blox
services portal
Device registration request
(brand mod el, HW revision….)
Device
Module
Device software
AT commands
Device profile UID (mandatory)
Device serial number (manda tory)
Customer –provisioned data
(optio nal)
DeviceProfileUID
Device maker
1
2
3
u-blox
software
RoT
4
4 Claim ownership
4.1 Automatic enrollment
Ownership can only be achieved by sealing a valid DeviceProfileUID into the customer’s devices. Once
customers have a service account, they can use the APIs to request a DeviceProfileUID and seal it in
their devices accordingly.
Secrets are provisioned into each module during the production process (the secrets are unique to
each module and are identified by the RoT public unique identifier - RoTPublicUID).
To claim ownership of individual devices, customers must first create a DeviceProfileUID using the
u-blox Thingstream Service management console.
The device profile unique identifier – DeviceProfileUID is equivalent to a model number and can be
used to identify a group of similar devices that need to have the same set of Security features enabled
at bootstrap.
Customers must then store the DeviceProfileUID into each device within the same group (normally
this is all the devices with the same type number). This is completed (either in their host firmware, e.g.
on device startup, or on their production line) by using the AT+USECDEVINFO AT command, along
with their own device serial number (this unique number for the device will be defined by the
customer).
☞ With the AT command you seal the DeviceProfileUID and the device serial number into the RoT;
they cannot be changed once they have been set – any subsequent calls to this AT command are
ignored. Please be careful on sealing the correct DeviceProfileUID generated through the u-blox
Thingstream platform.
Command
☞ Please note you can just do sealing procedure (via AT+USECDEVINFO) once and any future retry
will be ignored by the device.
Response Description
Seal the DeviceProfileUID and the device serial
number into the module.
Figure 3: Process to set DeviceProfileUID and device serial number
UBX-20013561 - R06 Claim ownership Page 11 of 53
C1-Public
IoT Security-as-a-Service - Application Note
Figure 4: Automatic enrollment of device process
Device profile unique identifiers (DeviceProfileUID) shall be used by the customer to “label” and claim
ownership of each device:
• Assign the DeviceProfileUID to the module using the +USECDEVINFO AT command
• Bootstrap the device in order to link it to the matching DeviceProfileUID created by u-blox
Once a device bootstraps, the system will recognize the DeviceProfileUID and assign ownership of the
device to the correct customer account (the company). It is then possible to configure the device
further using the functionality available in the u-blox services APIs.
The basic process for the customer to claim ownership of a device is:
1. Create the Device Profile UID.
2. Seal each DeviceProfileUID into the correct device(s).
3. Connect each device to the Internet.
4. Wait for each device to register to security services (monitor the status via AT+USECDEVINFO?
query).
5. The device should now be assigned into customer’s account and the device registration date
should be set.
UBX-20013561 - R06 Claim ownership Page 12 of 53
C1-Public
IoT Security-as-a-Service - Application Note
AT+USECDEVINFO?
Command
Response
Description
AT+USECDEVINFO?
+USECDEVINFO: 0,0,0
+USECDEVINFO: 1,0,1
+USECDEVINFO: 1,1,1
☞ Customers can enable IoT Security-as-a-Service on device(s) when they bootstrap. This option
removes the need to create similar campaigns once the bootstrap has been successful and means
the required IoT Security-as-a-Service features are immediately available following a successful
bootstrap.
4.1.1 Change the ownership
You have the possibility to change the ownership of a single device or a group of devices. There are
procedures in the u-blox back-end to handle it for you. Just write to services support (
support@u-blox.com)
•
DeviceProfileUID of the device(s) that the ownership should be changed
Current owner thingstream domain name
•
Future owner thingstream domain name
•
and please provide the following information:
thingstream-
4.2 Bootstrap and device assignment to the owner procedure
1. The module bootstraps to the u-blox security server (icpp.services.u-blox.com) when the actual
device first connects to the internet. The bootstrap process happens only once; if subsequent
power cycles occur, then the device is recognized as already being bootstrapped.
2. The process replaces the factory-provisioned secrets and adds the necessary keys to enable the
relevant features/services.
3. During bootstrap the device becomes associated with its registered owner (via the
DeviceProfileUID that was created) and any cloned devices are rejected.
4. The customer now has ownership of the device.
⚠ During the initial bootstrap it is recommended that the application does not try to reset or power
The bootstrap process requires 4 individual communication phases over which at least 1048 bytes
are transferred. The maximum amount of data that can be transferred will vary and can depend on:
1. Whether “Feature authorizations” data must be sent.
2. Whether retransmissions must be done because an original attempt failed.
3. Whether Internet Protocol version 4 (IPv4) or version 6 (IPv6) is being used.
The +USECDEVINFO can be called to confirm that the bootstrap attempt has either not yet finished
(that is, the current attempt was not successful, and another attempt will be tried) or the bootstrap
process has been successful.
Command
The response to the AT+USECDEVINFO? Query has the following meaning:
cycle the module until the process is completed successfully. The time needed to conclude the
process is strictly dependent on the RAT being used. If the bootstrap process is interrupted before
completion, the process will re-start from the beginning.
Description
Check bootstrap status.
The module is not able to reach the u-blox security service. No
bootstrap can be performed. Check that data connection is
available and a suitable APN has been set.
The module is registered to the u-blox security service and
bootstrap has started. Device has not been sealed with a
DeviceProfileUID yet.
OK
The module is registered to the u-blox security service and
bootstrap is complete.
UBX-20013561 - R06 Claim ownership Page 13 of 53
C1-Public
IoT Security-as-a-Service - Application Note
Device maker
(owner of Device
Profile UIDs)
Device
Module
u-blox
software
Device software
User can see device in the
portal
Device registration
Claim of ownership
Bootstrap message (RoT public UID,
bootstrap data)
u-blox services portal
Module Ro Tauthentication
Anti-cloning checks
Activation notification
Keys refresh, sec urity policies, features
authorization
Device activation
(RoT public UI D, Device Pr ofile UID, e tc.)
RoT
1
2
3
4
Command
AT+USECCONN
OK
If the bootstrap process is still in progress (that is, it has not finished or been successful or an error
condition has occurred), then the AT command will return an error.
☞ In SARA-R4 products, if the bootstrap process is still in progress, AT+USECDEVINFO? Will block
until the operation is complete.
☞ To prevent flooding the server with security heartbeat messages, if the command is issued within
Figure 5: Device bootstrap process
4.3 Two stage bootstraps
In some circumstances the bootstrapping of one or more devices may need to be completed in two
stages (two-stage bootstrap).
This is the scenario when the bootstrap happens when the DeviceProfileUID has not already been
sealed in the device. The device is registered but cannot be assigned to the correct customer.
When, at a later stage, the DeviceProfileUID is sealed in the device, it communicates with the u-blox
server and it is therefore assigned to the correct customer. The customer can then manage the device
using the u-blox Thingstream Management console or the APIs.
4.4 Security heartbeat
Once a device has successfully bootstrapped, it will continue to call the u-blox security service on a
regular basis: this is known as a “security heartbeat”.
By default, the security heartbeat occurs automatically once a week. It is possible, though, to trigger
a security heartbeat from the module by using the AT+USECCONN command:
Response Description
5 minutes of the last sent security heartbeat, the request will be rejected, and an error result code
will be returned.
Trigger a security heartbeat to the u-blox security service.
UBX-20013561 - R06 Claim ownership Page 14 of 53
C1-Public
IoT Security-as-a-Service - Application Note
Figure 6: Enrollment of devices with security heartbeat
4.4.1.1 Security heartbeats on SARA-R4
To prevent flooding the server with "security heartbeats", if the command is issued within 5 minutes
of the last sent "security heartbeat", the request will be rejected, and an error result code will be
returned. The system time is used for measuring elapsed time. When a "security heartbeat" is sent,
the system time is stored in NVM, therefore the value is persistent to power cycles. When an attempt
to send a "security heartbeat" occurs, the previous send time is checked against the current system
time, to see if the elapsed time is valid.
UBX-20013561 - R06 Claim ownership Page 15 of 53
C1-Public
IoT Security-as-a-Service - Application Note
4.4.1.2 Security heartbeats on SARA-R5
• The "security heartbeat" message operation is required to update the status of the security.
• The "security heartbeat" message operation is for security reasons required to be an atomic
message operation using a blocking send/receive cycle.
• The blocking send/receive cycle can execute up to 5 minutes (before timeout and abort) in case of
network issues.
• The blocking send/receive cycle can block (up to 5 minutes) the execution of the command
(affected commands listed below) which triggered the "security heartbeat" message operation.
• The "security heartbeat" message operation before executing the blocking send/receive cycle
verifies if the "security heartbeat" message shall be sent immediately due to security reasons.
• The "security heartbeat" message operation before executing the blocking send/receive cycle
verifies if the "security heartbeat" message shall be sent immediately due to server configured
time period elapsed.
To prevent flooding the server with "security heartbeats", if the command is issued within 24 hours of
the last sent "security heartbeat", the request will be rejected, and an error result code will be returned.
The system time is used for measuring elapsed time. When a "security heartbeat" is sent, the system
time is stored in NVM; therefore, the value is persistent to power cycles. When an attempt to send a
"security heartbeat" occurs, the previous send time is checked against the current system time, to
see if the elapsed time is valid.
4.5 Feature provisioning
Customers can activate/deactivate a feature in two ways:
• At device profile level: when the device profile is created using the Management Console. In this
case all devices that makes the bootstrap with that DeviceProfileUID, will get activated the
selected features. Be aware that if you change the Device profile definition at a later stage (i.e.
deactivating a feature previously enabled), this change will be applicable only to the devices that
make bootstrap from that time.
• At device level: on each active device you can activate/deactivate a feature at any time using the
Management console or the APIs
Activation/deactivation on the device happens at the next Security Heartbeat event after that you
have applied the new setting. You can monitor the status both from the API and the Management
console.
You can always trigger the Security Heartbeat as described in section 4.4
Feature provisioning is applicable to:
• Local Data Protection
• Local Chip-to-Chip Security
• Zero Touch Provisioning
4.5.1 Service provisioning
Symmetric KMS (PSK) and E2E data protection services are automatically provisioned during the
bootstrap process when the customer selects a price plan that includes also these services
(Developer, Daily, Flex, Freedom) during device Profile definition; therefore the services can be used
IMMEDIATELY after the bootstrap. In case the customer, during device profile creation, selects a
price plan that does not include the above services, they can be anyway activated in a later stage by
going in the Management console and associate a different price plan to the Security thing. As for
feature activation, the services will be enabled at the next Security Heartbeat.
UBX-20013561 - R06 Claim ownership Page 16 of 53
C1-Public
Loading...