Threat-Modeling Password Manager Emergency Access

This document is a design threat model, not a claim that Lockstep currently ships emergency access. It defines the standard a future implementation should meet before release.

Security objectives

The system should:

1. Preserve zero-knowledge vault encryption during ordinary operation.
2. Grant access only to contacts explicitly authorized by the owner.
3. Enforce the owner's selected waiting period and permission level.
4. Notify the owner through independent channels.
5. Permit reliable denial and revocation.
6. Prevent the provider from silently becoming the contact.
7. Limit the effect of compromise to the minimum granted scope.
8. Produce an auditable record without logging plaintext secrets.
9. Fail safely under partial outages and retries.
10. State residual risks honestly.

Assets to protect

• Plaintext vault records
• Vault keys and key-wrapping keys
• Contact private keys
• Owner and contact account credentials
• Pending access grants
• Permission and waiting-period settings
• Notification destinations
• Denial and revocation actions
• Audit history
• Device and session state

Metadata can also be sensitive. A contact relationship may reveal family, medical, business, or estate information even before vault access occurs.

Actors

Vault owner

Creates, limits, reviews, and revokes grants.

Trusted contact

Accepts the relationship and may request access under defined circumstances.

Provider

Stores encrypted data, enforces timing and policy, delivers notifications, and coordinates key release without gaining plaintext access.

External attacker

May target either account, device, email channel, network session, provider API, or support process.

Malicious insider

May alter databases, application code, builds, notifications, clocks, or approval state.

Authorized but abusive contact

Possesses legitimate credentials but requests access prematurely or uses granted information outside the owner's intent.

Trust boundaries

Important boundaries include:

• Owner device to provider API
• Contact device to provider API
• Browser or app to local cryptographic module
• Provider application to database
• Provider to email or notification service
• Build system to distributed client
• Support personnel to administrative tools

Client-side encryption does not neutralize a malicious client update. If the provider can ship code that captures a master password or unwrapped key, software distribution remains a major trust boundary.

Threat 1: Contact-account takeover

An attacker compromises the trusted contact and requests access.

Required defenses

• Strong MFA for contacts
• New-device alerts
• Risk-based reauthentication before requests
• Master-password reprompt or equivalent local authorization
• Owner-selected delay
• Multiple owner notifications
• Clear request details, including contact, device, time, and location indicators
• Rapid denial and contact revocation

Phishing-resistant MFA is preferable. CISA says organizations should aim for phishing-resistant methods in its MFA guidance, and NIST requires a phishing-resistant option at AAL2 in SP 800-63B.

Threat 2: Wrong or intercepted invitation

The owner mistypes an email address or an attacker intercepts the invitation.

Required defenses

• Display the resolved account identity before confirmation.
• Require the contact to accept while authenticated.
• Show a verifiable key fingerprint or use a secure authenticated key-establishment process.
• Notify the owner after acceptance.
• Keep the grant inactive until both sides complete confirmation.
• Make revocation immediate.

Email proves control of an inbox, not the human relationship. Encourage out-of-band verification.

Threat 3: Provider substitutes a key

The provider or an attacker changes the contact public key and causes the owner to encrypt grant material to an attacker-controlled key.

Required defenses

• Bind contact identity to key material.
• Sign key records or use transparency mechanisms.
• Warn on key changes.
• Require owner reauthorization after a key change.
• Retain an auditable key history.
• Test for server-side key substitution.

Asymmetric encryption alone does not solve identity. It protects data for whoever owns the selected private key; the system must ensure that key belongs to the intended contact.

Threat 4: Waiting-period bypass

An attacker manipulates timestamps, queues, database state, or application logic to release access early.

Required defenses

• Authoritative server-side timing
• Monotonic or tamper-evident event history where practical
• State-machine enforcement rather than scattered booleans
• Idempotent transitions
• Separation between request creation and grant release
• Tests for clock changes, retries, race conditions, and duplicate jobs
• Alerts on administrative overrides

No employee should be able to shorten a delay silently.

Threat 5: Notification suppression

An attacker changes the owner's email, filters warnings, compromises the notification provider, or blocks messages.

Required defenses

• Notify through multiple independent channels where available.
• Delay sensitive email-address changes.
• Notify old and new addresses after destination changes.
• Show persistent in-app warnings.
• Record delivery attempts and failures.
• Do not treat notification delivery as proof that the owner actually saw it.

The waiting period compensates partly for missed alerts, but silence must ultimately trigger access for the system to work during incapacity. This is an unavoidable tradeoff.

Threat 6: Owner account compromise

An attacker who controls the owner account adds their own contact, reduces the wait, or grants access immediately.

Required defenses

• Strong reauthentication for adding or changing contacts
• Delay before new grants become active
• Notifications through prior channels
• Cooldown after lowering a waiting period
• Review screen listing every contact and permission
• Device and session revocation

Changing a recovery path is at least as sensitive as changing the master password.

Threat 7: Revocation failure

The owner removes a contact but previously issued encrypted grant material remains usable.

Required defenses

• Define whether revocation prevents future release or invalidates already released keys.
• Rotate or rewrap affected key material where necessary.
• Expire pending requests.
• Revoke sessions created through emergency access.
• Confirm revocation across every client and cache.

Cryptography cannot make a contact forget plaintext already viewed. Product copy must not imply otherwise.

Threat 8: Excessive scope

A household contact receives business credentials, private correspondence, or irreversible cryptocurrency access.

Required defenses

• Separate vaults or collections
• Per-vault grants
• View versus takeover permissions
• Optional item-level exclusion
• Clear preview of access scope
• Least-privilege defaults

If granular access is not possible, say so explicitly before the owner confirms.

Threat 9: Contact dies, disappears, or becomes hostile

Emergency relationships decay.

Required defenses

• Multiple optional contacts
• Annual review reminders
• Last-confirmed date
• Easy replacement and revocation
• Clear priority or independent-access rules
• No assumption that the closest relative is appropriate

NIST recommends annual review reminders for recovery contacts in SP 800-63B.

Threat 10: Provider outage or shutdown

A request is pending when the service disappears, or the key release depends entirely on a provider job.

Required defenses

• Document offline and shutdown behavior.
• Provide export and recovery options that users can test.
• Avoid representing provider-dependent access as permanent continuity.
• Define what happens to pending grants during service restoration.
• Ensure retries cannot release twice or bypass denial.

See What Happens If Your Password Manager Shuts Down?.

Threat 11: Malicious client or supply-chain compromise

A compromised build captures plaintext or changes the contact key.

Required defenses

• Locked dependencies and reproducible or independently verifiable builds where practical
• Code review for cryptographic and authorization changes
• Signed releases
• Narrow dependency surface
• Content Security Policy and extension isolation
• Independent security assessment
• Incident-response ability to revoke bad releases

OWASP warns that cryptographic designs are easy to weaken through implementation mistakes in its Cryptographic Storage Cheat Sheet. Standard primitives are necessary but not sufficient.

Proposed secure state machine

A future implementation should model explicit states such as:

1. invited
2. accepted_pending_activation
3. active
4. access_requested
5. denied
6. approved_pending_release
7. granted
8. revoked
9. expired

Every transition should define:

• Authorized actor
• Required reauthentication
• Timing condition
• Notification behavior
• Audit event
• Key-material action
• Retry behavior
• Revocation consequence

Booleans such as isApproved and hasAccess are inadequate for a security-critical asynchronous workflow.

Residual risks that cannot be eliminated

• A correctly authorized contact can misuse plaintext after receiving it.
• The owner may miss every notification.
• A compromised endpoint can expose an unlocked vault.
• A malicious software update can attack client-side secrets.
• Legal authority may conflict with the owner's technical grant.
• No waiting period perfectly balances fraud detection and urgent access.
• Revocation cannot retract secrets already copied.

These are not reasons to abandon emergency access. They are reasons to avoid claiming it is risk-free.

Release criteria for Lockstep

Lockstep should not advertise emergency access until:

• The cryptographic grant protocol is documented.
• Contact identity and key changes are authenticated.
• Permission scope is explicit.
• Waiting-period transitions are tested for races and retries.
• Denial and revocation behavior is verified.
• Owner and contact MFA requirements are defined.
• Notifications use more than one channel where practical.
• Audit events contain no vault plaintext.
• A third-party security review is completed.
• Recovery, outage, and shutdown limitations are published.

For the user-facing model, see Password Manager Emergency Access. For current competitor approaches, see Emergency Access Comparison.

The bottom line

The core emergency-access problem is not scheduling an email after seven days. It is securely transferring decryption capability under a policy that remains correct when accounts, devices, employees, databases, notification systems, and relationships are compromised.

Any implementation that cannot explain its key path, state transitions, revocation limits, and residual risks is not ready to protect a vault.