The following changes to the Surfsight API may impact your use of the service.   

  • Security updates for AI-14 Encryption 

  • Wrong PIN 

  • PIN Randomization  


Summary 

This update raises default security measures across storage, access, and audit, and it requires changes before deployment to avoid disruption. For AI-14, these changes arrive with firmware 14.6. See the link to AI-14 14.6 release notes: AI-14 dash cam firmware V14.6 release (BETA) . AI-14 enforces SD card encryption and validates key strength. AI-14 enables wrongPinCode by default and does not allow disabling it. PIN reads move to dedicated endpoints while PIN changes stay in the existing settings APIs. On first connection, fleets with a PIN policy apply it. If no policy exists, AI-12 and AI-14 randomize the default administrator and driver PINs to four digits. Update integrations, UI, and runbooks before the effective date. 

What is changing? 

AI-14 SD card encryption 

  • First provisioning enables encryption on AI-14, and the platform generates a compliant key. 

  • After a factory reset the device starts encrypting with a newly generated key. 

  • At boot after reset the device ignores any organization profile recordingEncryption, true or false. 

  • Encryption cannot be disabled on AI-14, and weaker keys are rejected when a key is set. 

Key format rules for AI-12 and AI-14 

  • Option 1 - 32 character printable ASCII string with no spaces. Include at least two lowercase letters, two uppercase letters, two digits, and two special characters. 

  • Option 2 - 44 character base64 encoded string that represents 32 bytes of binary data. 

  • The built-in generator is recommended for provisioning and rotations. 

Key management APIs for AI-12 and AI-14 

  • These APIs are optional and provided for ease of key management. 

  • Strong key generation, POST /generate-encryption-key, returns a random compliant 32-character encryption key you can apply to a device. 

  • Key history, GET /devices/{imei}/recording-encryption-keys, returns prior keys with encryptionType, device receipt confirmation, and a timestamp for each entry. 

  • Key setting flow 

  • Set or rotate a recording encryption key only with the single device settings endpoint, PUT /devices/{imei}/device-config. 

  • Bulk settings and organization profile settings do not support setting or rotating recording encryption keys. These paths are removed. 

  • Continue to use key history for read only audit through GET /devices/{imei}/recording-encryption-keys. 

Encryption key field removal for AI-12 and AI-14 

  • The recordingEncryption field is removed from the Bulk Devices API and the Organization Profiles API for AI-14 and AI-12. 

  • The single Device Settings API keeps the recordingEncryption field for both, GET/PUT /devices/{imei}/device-config. 

Organization profile and reset behavior for AI-14 

  • After reconnect the cloud restores the previous per device configuration, including the prior encryption state and key, if one exists. The cloud does not revalidate strength in this restore path. 

  • A device side reset and a cloud initiated reset without an active organization profile both restore the prior configuration after reconnecting. 

  • New AI-14 devices do not operate unencrypted after reset. Existing devices can remain with their previous state until you change the key. 

Administrator and driver PIN code policy 

“wrongPinCode” event enforcement for AI-14 

  • The Wrong PIN code event is enabled by default on AI-14, event key wrongPinCode. 

  • Removing or disabling this event from the API or the White Label Portal UI is not allowed. 

  • The event triggers on the first wrong PIN attempt, not after the third. 

  • Media configuration remains editable. Supported values are none, snapshot, and video. 

  • PUT /devices/{imei}/event-config accepts dataType values snapshot and video for wrongPinCode. 

  • PUT /organizations/{orgId}/event-settings accepts dataType values snapshot and video for wrongPinCode. 

  • Bulk event configuration for wrongPinCode accepts dataType values snapshot and video where applicable in your bulk events configuration API. 

  • If there is no prior configuration, the system enables wrongPinCode with dataType: "none", which sends the event as metadata with no media attached. 

PIN policy and randomization on first connection for AI-14 

  • AI-14 devices are shipped with default administrator and driver PINs. 

  • If a fleet PIN policy exists at first connection, the device applies the policy PINs. No randomization occurs. Policy takes precedence. 

  • If no fleet PIN policy exists at first connection, the device randomizes each default to a new four-digit PIN. 

  • After a factory reset the device will receive the previously configured PIN or receive a new randomized PIN if was not yet configured by the user. 

PIN retrieval changes for AI-12 and AI-14 

  • Use GET /devices/{imei}/pin-codes to read administrator and driver PINs for a device. 

  • Use GET /organizations/{orgId}/default-settings/pin-codes to read the organization default PIN policy. 

  • Single device settings endpoint, GET/PUT /devices/{imei}/device-config, and organization profile device settings endpoint, GET/PUT /organizations/{orgId}/device-settings, return masked PIN values like **** in responses. 

  • Prior PIN reads through device config are deprecated for clear values. 

  • Changing PINs is unchanged. Continue to use PUT /devices/{imei}/device-config for single device changes, bulk settings APIs for bulk changes, and PUT /organizations/{orgId}/device-settings for organization profile changes. 

  • The White Label Portal UI allows administrators to view masked PINs in settings, reveal current PINs through the new read flows, and update administrator and driver PINs according to role-based permissions. 

Who is affected? 

  • Partners and customers that manage AI-14 fleets for encryption and wrongPinCode enforcement. 

  • Partners and customers that manage AI-14 fleets for PIN policy and PIN retrieval changes. 

  • AI-12 fleets are affected by the removal of recordingEncryption from Bulk Devices and Organization Profiles APIs. Use the single Device Settings API for key management. 

  • AI-14 partners and customers that are using wrongPinCode event. Reporting is always on and PIN reads move to new endpoints. 

Actions to complete before Feb 7, 2026 

  • Remove recordingEncryption from Bulk Devices and Organization Profiles API requests for AI-14 and AI-12. Keep it only in single Device Settings requests, GET/PUT /devices/{imei}/device-config. 

  • Update integrations and portal logic to handle validation errors for weaker keys. 

  • For AI-14, rely on automatic key generation at add, or call POST /generate-encryption-key, then apply the key using PUT /devices/{imei}/device-config. 

  • Delete any bulk or organization profile workflows that attempted to set or rotate recording encryption keys. 

  • Move PIN reads to GET /devices/{imei}/pin-codes and GET /organizations/{orgId}/default-settings/pin-codes. 

  • Confirm that only elevated roles can read PINs and key history, and that every read is audited with actor, device, org, reason, and IP. 

  • Train support teams on the new PIN read endpoints, masking behavior, the policy over randomization precedence, and the key history view. 

Why we are making this change 

This raises the default security posture to support compliance with Radio Equipment Directive (RED), removes weaker defaults at scale, and strengthens auditability by separating PIN reads, consolidating key set flows to a single device API, adding centralized key generation, and providing key history visibility. 

Support 

The rollout starts on Feb 7, 2026. We understand that these changes may cause some disruption to your workflow, and we apologize for any inconvenience. If you have any questions or concerns, please reach out to your Technical Account Manager.  Thank you for your understanding and continued support. 

Disclaimer and trademark information 

The terms "partner" or "partnership" refers to a collaborative relationship and does not imply a legal partnership or joint venture. 

NOTE: Lytx, Inc. owns the LYTX and SURFSIGHT trademarks and other related trademarks and logos. The TM or SM refer to a trademark or service mark, respectively, used by Lytx, Inc. The ® symbol refers to a trademark registered in the USA and elsewhere.