Lost devices, revocation, fallback and status checks.
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.
Recovery should invalidate credentials bound to the lost device and enroll replacement hardware-backed credentials after policy-compliant identity checks. Soft OTP-only bypasses, if used temporarily, should not become permanent substitutes for hardware-verified security. Detailed SIM, eSIM and iSIM recovery runbooks remain product-confirmed editorial tasks.
Report suspected vulnerabilities through Keyra’s official security contact channels published on keyra.ie or accompanying developer documentation—not through public social media. Include affected product, version if known, and reproduction context without sharing secrets. Expect coordinated disclosure norms; do not exploit production systems.
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.
Check device eligibility, network connectivity, application updates and whether your carrier subscription still hosts the required security application. Sign out and back in only if support directs that step. If failures persist, use official support paths and capture non-sensitive error codes for diagnostics.
