Security

Keyra secures authority.
It does not remove asset-class risk.

CISO-grade threat model and claim discipline.

What Keyra protects—and what it does not eliminate. No marketing fluff.

Request a Security ReviewStandards methodology

Claim discipline

What Keyra does — and does not

Keyra protects authorization, hardware, policy, and recovery. It does not remove chain, market, or smart-contract risk.

In scope

What Keyra protects

  • Authorization

    Hardware-rooted approval of high-value intent—before a wallet or agent acts.

  • Hardware credential

    Physical Daily and Vault authority. Not a software seed or shared secret.

  • Policy

    Who may authorize, under what limits, and when those limits apply.

  • Device identity

    Actions bound to a specific hardware endpoint the owner holds.

  • Recovery process

    Governed replacement of lost authority—not an unrestricted backup path.

  • Trusted transaction intent

    Signed intent the wallet or agent is permitted to execute.

These protections apply only where the integration uses Keyra for authorization. Possession of a card does not by itself secure every wallet, chain, or custodian path.

Out of scope

What Keyra does not eliminate

  • Chain halt

    L1 or L2 unavailability is outside Keyra’s control plane.

  • Chain reorganization

    Consensus history is a protocol risk, not an authorization risk.

  • Smart-contract bugs

    Contract logic remains the issuer’s and protocol’s surface.

  • Bridge failure

    Cross-chain infrastructure is not Keyra’s custody or settlement layer.

  • Stablecoin depeg

    Issuer and market risk are not removed by authorization.

  • Validator compromise

    Network-operator failure is a chain-layer event.

  • Network congestion

    Broadcast delay does not void ownership or prior intent.

  • Market risk

    Price movement is not a Keyra security guarantee.

Architecture

Threat model

Do not claim Keyra mitigates categories not supported by architecture. Mitigations below are design targets where labelled.

  1. Prevent
  2. Detect
  3. Contain
  4. Recover

Remote

Phishing, malware, browser compromise, phone compromise, cloud compromise, SIM swap.

Prevent
Hardware-rooted step-up for high-value actions; phishing-resistant presentation of intent.
Detect
Policy anomalies, new destination, device trust signals (where integrated).
Contain
Suspend credential; pause agent sessions; require elevated authority.
Recover
Governed recovery tiers; revoke lost authority.

Hardware

Stolen card, counterfeit, cloning, tamper, side channel.

Prevent
Secure manufacturing assumptions; attestation where designed; dual-card model.
Detect
Attestation failures; anomalous use after reported loss.
Contain
Immediate suspension of lost Daily credential.
Recover
Vault / recovery factors; provision replacement; revoke old credential.

Recovery

Social engineering, fake replacement, insider fraud, stolen recovery credential.

Prevent
Waiting periods; multi-party thresholds; distinct Vault authority.
Detect
Recovery attempt monitoring; policy review gates.
Contain
Freeze elevated paths pending verification.
Recover
Institutional / legal escalation where configured.

Infrastructure

HSM, APIs, merchants, custodians, exchanges.

Prevent
Least privilege; partner segregation; no private-key collection.
Detect
API anomaly and authorization evidence mismatch.
Contain
Fail closed on material intent changes.
Recover
Re-authorize; resume when partner paths healthy—ownership ≠ availability.

Supply chain

Firmware, factory, personalization, counterfeit distribution.

Prevent
Controlled personalization; design decisions still open where labelled.
Detect
Attestation / serial integrity checks (target architecture).
Contain
Revoke suspect batches.
Recover
Re-provision under policy.

Human

Coercion, mistake, loss, destruction, succession dispute.

Prevent
Clear UX; cooling periods; role separation.
Detect
Unusual patterns; dual control for high value.
Contain
Pause; require second approver.
Recover
Estate / trustee process where legally valid—legal review required.

Privacy

Verified does not have to mean exposed

Proof of human authorization does not require publishing a wallet as a legal identity.

Minimum necessary disclosure

Share only what a given authorization requires.

Selective disclosure

Prove an attribute without exposing a full identity.

Pseudonymous interaction

Interact where permitted without publishing a legal name.

Credential privacy

Authorization proof is not a public identity document.

Merchant-data separation

Merchant records stay apart from Keyra credential data.

Retention governance

Keep evidence only as long as policy requires.

Informed consent

The owner knows what is being proven, and to whom.

Scoped institutional access

Institutions see only what policy grants.

Never connect a user's public wallet address to legal identity unnecessarily. Never ask for or store seed phrases or private keys.

Continuity

Graceful failure

If Keyra service, internet, chain, or custodian is unavailable, distinguish ownership, authorization, broadcast, and settlement. The owner should not lose ownership merely because infrastructure is temporarily unavailable.

  • Ownership

    The owner should not lose ownership merely because infrastructure is temporarily unavailable.

  • Authorization

    Hardware-rooted intent stays distinct from whether a network can currently carry it.

  • Broadcast

    Internet, chain, or partner downtime can pause delivery without voiding authority.

  • Settlement

    Custodian and chain completion remain separate from who still holds the asset.

Request a security review

CISO-grade diligence without marketing fluff.

Request a Security ReviewStandards