People verifying identity, approving sensitive requests and managing devices.
Start path: /audiences/individuals
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.
Keyra addresses weak software-only authentication and fraud-prone approval of sensitive actions by anchoring verification in hardware-backed mobile security. Public materials highlight identity verification, sensitive-request approval, network verification themes and privacy-conscious consent. The Ciright Cyber One lineage historically targeted passwordless MFA for workforce and developer scenarios.
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.
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.
Start at keyra.ie for official product navigation and access pathways. Public messaging references iPhone TestFlight beta and Android early access for supported users. Technology explanations are published at app.keyra.ie/technology. Treat other keyra.ie subdomains as investigation seeds until independently verified for your use case.
Not necessarily. Company declaration states current hardware-verified security runs on SIM, eSIM and iSIM, extending beyond the physical Cyber One Card. A physical card may still matter for specific programs or historical deployments, but public Keyra consumer messaging centers on mobile verification pathways.
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.
Support is eligibility-based, not universal. Public Keyra messaging references iPhone TestFlight beta and Android early access, which implies selected device pathways rather than every phone or carrier. Company declaration of SIM, eSIM and iSIM implementations does not assert global MNO coverage or identical feature sets worldwide.
Changing phone, number or carrier can affect subscription binding, security-application eligibility and recovery steps. Because Keyra hardware-verified security is declared on SIM, eSIM and iSIM, re-provisioning or re-enrollment may be required. Exact recovery flows that preserve the hardware trust boundary need product-confirmed runbooks.
Roaming may allow ordinary connectivity, but Keyra hardware-verified features depend on device eligibility, provisioned security applications and verifier reachability—not on roaming alone. Treat roaming support as conditional until a carrier or product guide confirms the feature set for your subscription plan.
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.
Compromise response should revoke or suspend affected credentials, rotate keys where supported, and re-enroll on a trustworthy form factor. Hardware-verified designs aim to contain software malware impact, but physical theft, insider misuse or flawed recovery can still create risk. Use only confirmed revocation channels.
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.
