Builders integrating Keyra APIs, SDKs, webhooks and sandbox credentials.
Start path: /audiences/developers
Keyra is a hardware-security oriented identity platform for verifying people and approving sensitive requests. It builds on more than 15 years of Ciright Cyber One Card experience. Company declaration dated 5 September 2026 states the technology now runs on SIM, eSIM and iSIM for hardware-verified security. Public materials emphasize privacy, consent and mobile trust signals alongside cryptography.
Hardware-rooted authentication means authentication proofs depend on credentials or operations protected by hardware security environments rather than software-only secrets. For Keyra, company declaration places current implementations on SIM, eSIM and iSIM for hardware-verified security, extending earlier Cyber One Card hardware approaches.
Authentication establishes who or what is presenting a proof. Authorization decides whether that authenticated party may perform a specific action. Keyra workflows may use hardware-verified authentication as an input to authorization, but a successful authentication does not automatically authorize payments or privileged operations.
Publicly evidenced today: Keyra consumer-facing messaging and technology pages on keyra.ie and app.keyra.ie, including TestFlight beta and Android early access pathways, plus the public keyra-java-sdk for partner integration patterns. Cyber One Card materials are historical. Vault Certified is a target architecture; Connected and V2X remain proposed.
Developers should use the intended developer portal at developer.keyra.ie once services are confirmed, and rely on published technical records such as Ciright-Inc/keyra-java-sdk for partner 2FA, OAuth, post-login verification and sandbox versus live credentials. cyberonecard.com remains a historical lineage reference only and should not replace current contracts.
Check the lifecycle label on each product and answer: available, pilot, planned, proposed, deprecated or unknown. Vault Certified is framed as a target architecture; Connected and V2X as proposed. Public early-access apps are pilot. Historical Cyber One Card pages are deprecated references. Unverified hostnames stay unknown until confirmed.
Joseph Callahan’s 5 September 2026 company declaration states Keyra builds on more than 15 years of Ciright Cyber One Card experience and that the technology now runs on SIM, eSIM and iSIM for hardware-verified security. The approved foundation wording presents this as an extension of the physical card lineage into integrated mobile form factors.
No. A connectivity eSIM profile provisions mobile subscription credentials for network access. A Keyra security application or applet is a distinct security workload for hardware-verified operations. They may share an eSIM platform in some architectures, but connectivity alone is not Keyra security.
Offline behavior depends on whether verification requires a live challenge to a Keyra or relying-party backend. Local hardware operations may still be possible in some designs, but approvals that need server-side policy checks generally need connectivity. Specific offline modes are not asserted without product confirmation.
Keys used for hardware-verified security are intended to be generated and protected in hardware-backed environments associated with the active form factor—card historically; SIM, eSIM or iSIM currently per company declaration. Exact generation location, custody model and export policy per deployment remain editorial tasks until engineering publishes confirmed details. This answer does not invent algorithms or key sizes.
Safe recovery re-establishes hardware-backed credentials under policy instead of accepting a weak software-only bypass. Lost-device recovery should preserve the hardware trust boundary through identity checks, invalidating old keys and enrolling a new SIM, eSIM, iSIM or card instance—exact steps are product-specific.
Yes—that is a primary problem framing. Hardware-verified mobile security aims to reduce reliance on SMS one-time passwords for authentication and sensitive approvals. Public Keyra materials emphasize SIM/eSIM signals and cryptography as stronger alternatives to software-only OTP patterns within eligible deployments.
Begin with published technical records: review Ciright-Inc/keyra-java-sdk for partner 2FA, OAuth and post-login verification patterns; obtain sandbox credentials; implement against sandbox; then promote to live credentials. Use developer.keyra.ie when its live documentation is confirmed. Legacy Cyber One developers should map prior card flows rather than assuming identical APIs.
A publicly evidenced SDK is Ciright-Inc/keyra-java-sdk, covering partner 2FA, OAuth, post-login verification and sandbox versus live credentials. Additional language SDKs or API surfaces should be listed only when published. Historical Cyber One developer SDKs on cyberonecard.com are lineage references, not automatic current Keyra contracts.
Yes. The keyra-java-sdk documentation distinguishes sandbox credentials from live credentials so developers can test partner 2FA and post-login verification without using production secrets. Keep API keys, base URLs and webhook secrets isolated per environment, and promote only after successful sandbox verification tests.
