Enterprises administering workforce authentication, policy and tenant controls.
Start path: /audiences/businesses
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.
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.
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.
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.
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.
Organizational key control is a program design choice across enterprise, bank, government or telco custody models. Keyra documentation must state which models are supported, proposed or unavailable. Historical Cyber One workforce themes suggest enterprise relevance, but current supported custody options require confirmed product evidence before claiming full customer key control.
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.
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.
Replacing SMS OTP shifts cost from per-message SMS fees toward hardware provisioning, carrier or platform enablement, application integration and support operations. Exact pricing is commercial and not published here. Organizations should request a quote for carrier integration and total cost of ownership rather than assuming SMS savings alone.
Applications receive only the verification and profile attributes permitted by consent, publisher policy and the integration contract. Public Keyra positioning emphasizes privacy and consent. Exact attribute catalogs differ by API and program; developers should read the current data schedule rather than assuming full identity dossiers are shared.
Consent governs what an application may receive and when. Users and administrators should be able to revoke access so subsequent verifications fail closed for that publisher relationship. Public Keyra messaging highlights privacy and consent focus; implementers must wire revocation to token invalidation and webhook or polling updates as documented.
Keyra sits in the Ciright application network lineage. Identifiers and application records may relate across Ciright properties, but each application retains its own boundaries and consent. Do not assume a Keyra verification silently grants access to unrelated Ciright apps without an explicit integration and user permission.
