Version 2.5.0 (12th August 2026)

🚀 What’s New in CyberRock

We're excited to announce CyberRock 2.5.0, which simplifies the Token and Host Mutual Authentication flows, streamlines the Host Response Word request, and expands Ephemeral Key (EK) support with optional public-key encryption, alongside privacy and messaging improvements.

🔐 Simplified Mutual Authentication

Mutual authentication lets a device and the server verify each other's identity before a trusted session or token is issued, so neither side has to trust the other blindly. The server issues a challenge, the device proves it can produce the correct response, and the server confirms the result. Because the exchange runs in both directions, it's called mutual authentication.

In CyberRock 2.5.0, the existing Token and Host Mutual Authentication flows have been made simpler and shorter, reducing the number of calls needed to complete authentication:

• Token Mutual Authentication is now a streamlined flow: request a challenge word (CW) for the token ID (TID), reply with the computed response word (RW), and check the authentication status.
• Host Mutual Authentication is now a streamlined flow: submit the host challenge word (HCW) and host response word (HRW), then check the authentication status.

For reference, please consult our document for Token Mutual Authentication & Host Mutual Authentication.

🔒 Privacy Policy Popup

Users are now presented with a privacy policy popup, making it easy to review how their data is handled directly within the experience, improving transparency and supporting compliance.

⚠️ Failed Authentication Description

When authentication doesn't succeed, CyberRock now provides more detailed descriptions of the failure. This added context makes it easier to understand why an attempt failed and to resolve it quickly.

⚙️ Request HRW Optimization

We're simplifying the Host Response Word (HRW) request by removing the separate Request Transaction ID step. The flow is now shorter and requires one fewer call.

These are the affected endpoints:

🔑 EK Phase 3 Implementation

We're adding an optional recipientPublicKey parameter to the first endpoint of each authentication type. If a recipientPublicKey is provided, an encrypted Ephemeral Key (EK) is returned; otherwise, the EK is returned as plain text.

These are the affected endpoints:

For reference, please consult our API Documentation.