Mistake on this page? Email us

Release notes

We recommend that you always use the latest versions of Factory Configurator Utility (FCU) and Device Management Client.

If you do not use the latest versions of FCU and Device Management Client, check the release notes for feature compatibility and bug fixes.

Device Management Client release notes

Please see Device Management Client release notes.

Factory Configurator Utility (FCU) release notes

To update an existing FCU installation, use pip install --upgrade <fcu-package>.

Release 1.2.16 (Feb 1st 2021)

  • Added ability to provision different custom properties per device by defining device-specific custom properties in separate YAML files. For more information, see Custom properties.
  • Updated FCU to support Python 3.6-3.9. Discontinued support for Python 3.5.

Release 1.2.15 (Jun 18th 2019)

Bug fixes

  • Environment variables used in fcu.yml were not resolved when using a new version of the PyYaml python package with FCU.
  • Fixed broken links in documentation.

Release 1.2.14 (May 5th 2019)

Bug fixes

  • FCU now returns an error when you provide an unknown parameter for a custom property of type generated-certificate-key-pair.

Release 1.2.13 (Apr 8th 2019)

Bug fixes

  • Custom properties of different types can now share the same name. Note that custom properties of types private-key, public-key, and certificate can still not have the same name as properties of type generated-certificate-key-pair.

Release 1.2.12 (Mar 28th 2019)

New features

  • You can configure multiple certificate authorities to sign custom-generated device certificates in the factory. When you use a custom property of type generated-certificate-key-pair, you can configure an additional certificate authority that can sign device certificates.

Deprecation notes

  • FCU/ft_demo setup no longer generates a proof_of_possession.txt file under the keystore folder. The use of the signature parameter is deprecated when you upload trusted certificates to Izuma Device Management.

Release 1.2.11 (Mar 3rd 2019)

New features

  • X.509 authority key identifier (AKI) and subject key identifier (SKI) certificate extensions are now supported. These extensions are added to the FCU certificate upon setup. If the extensions exist in the FCU certificate, they are generated for the device certificates signed by FCU.

Release 1.2.10 (Feb 24th 2019)

Bug fixes

  • Custom properties: name is now restricted to 100 characters and only supports the characters A-Z, a-z, 0-9, . _ -.

Release (Sep 20th 2018)

Bug fixes

  • Certificate chains: certificate chain depth of 2 is now enabled in case certificate is generated by FCU and fcu.crt file does not contain a certificate chain.

Release (Aug 23rd 2018)

Bug fixes

  • Updated FCU python requirements to support installation with Python 3.7.

Release 1.2.9 (Jul 3rd 2018)

New features

Certificate chains

Izuma Device Management and FCU now allow a more flexible PKI infrastructure with various options to configure your CA hierarchy.

  • DTLS certificate chain injection
    If you use an intermediate CA for issuing device certificates, you can add a CA to Device Management that will be higher in the hierarchy than the intermediate CA.
    To enable a TLS handshake, the device needs to store the chain of trust up to your trusted CA. You can do this by:

    1. Providing a certificate chain for the device certificate (when bringing your own certificate).
    2. Updating the value of device-certificate-chain-depth in the FCU configuration file to the level that you want to store on the device. If FCU generates your device certificate, you need to configure the FCU certificate itself as an intermediate CA.
  • Custom certificate chains injection
    You can now use certificate chains when provisioning your own custom certificates. You can add a certificate chain to the PEM certificate data or file pointer in the FCU configuration file (under custom-properties, items of type certificate). Each such item must define the depth of the chain to be stored on the device, by giving a value to chain-depth-on-device.

  • FCU as an intermediate CA
    You can now set up FCU as an intermediate CA by following these steps:

    1. In the FCU configuration file, set setup-ca-as-intermediate to true.
    2. Set up FCU by using the Python APIs or the ft_demo setup command. This creates a private key and CSR file.
    3. Sign the CSR with your own CA.
    4. Provide FCU with the file fcu.crt containing the certificate chain.
      Note: When you use FCU as a certificate authority, if fcu.crt is a certificate chain, you must specify a device-certificate-chain-depth value in the FCU configuration file.

Certificate chains only work on devices running Device Management Client 1.4.0 or higher.

Release 1.2.8 (Mar 14th 2018)

New features

Entropy injection

A new configuration parameter entropy-generation-mode introduced. Available options:

  • by_device (default): FCU will not pass the entropy, as it is generated by the device.
  • externally_supplied: Entropy that you supply. FCU expects to find it under device_keys_location (an API parameter).
  • by_tool: Entropy generated by FCU.

This feature requires the client version R1.3 or higher.

Disable factory flow

You can now control whether the factory flow can be applied again on the device. Using FCU, you can provide the parameter factory_fcc_disable when using the FactoryToolApi.prepare_device_configuration API. Using the Factory Tool demo, to disable the factory flow, add the parameter --factory-fcc-disable to the inject command.
This feature requires the client version R1.3 or higher.

Verify on device

You can now control whether or not to verify the configuration on the device side. To do that, enable/disable verify-on-device in the FCU configuration file (default: true).

Release 1.2.7 (Feb 20th 2018)

New feature: Custom properties

Provisioning of user-defined properties is now available in the custom-properties section of the FCU configuration file.

Release 1.2.6 (Feb 6th 2018)

New feature: First-to-claim

OEM customers can now use the First-to-claim feature by enabling first-to-claim in the FCU configuration file, specifying bootstrap-server-uri-first-to-claim. Each device will be provided with an enrollment ID (enrollment-id) that an account can use to claim the device. This feature requires the client version R1.2.6 or higher.

Release 1.2.5 (Nov 5th 2017)

The certificate authority private key file name generated in the setup command is changed to fcu_private_key.pem.

Release 1.2.4 (Oct 24th 2017)

Removed the following configuration file entries:

  • bootstrap-server-crl-file
  • lwm2m-server-crl-file
  • update-auth-crl-file.

Release 1.2.3 (Oct 9th 2017)

Bug fix: Firmware updates require vendor-id and class-id in UUID format. Added the vendor-id and class-id configuration parameters to support this. They are required when update-auth-certificate-file is used.

Release 1.2.2 (Sep 27th 2017)

  • Bug fix: Devices generated in factory could not verify the online firmware update. As part of this fix, the following configuration file entries changes were applied:
    • Changed: firmware-integrity-certificate-file was renamed to update-auth-certificate-file.
    • Changed: firmware-integrity-crl-file was renamed to update-auth-crl-file.
    • Removed: The configuration file entry firmware-integrity-ca-certificate-file.

Release 1.2.1 (Sep 4th 2017)

  • Bug fix: Use the Python cryptography package version 2.0.3 to avoid conflicts with the pycparser package found in some Python installations.
  • The factory tool now provides more informative logs. The default log level of the factory tool demo is info.
  • Sensitive information was removed from the logs of both FCU and the factory tool demo.

Release (Aug 6th 2017)

  • The factory tool demo application ft_demo is no longer provided as a Windows executable binary due to US export control limitations. You can still execute the demo application using its sources.
  • The factory configurator utility (FCU) has improved user input validation. Old configurations that do not comply with the validation scheme will require manual migration.
  • Logging:
    • The ft_demo application no longer writes audit logs into a separate file. Instead, the FCU logs will include a line for each API execution, in the format: AUDIT: <operation name> completed <successfully/with errors/with warnings> [endpoint name] [account id].
    • The FCU logs are now written using the fcu logging module.
    • The ft_demo log file is now rolled over at 10MB. There is a maximum of five backups, for a total of six log files.