Every device is known and revocable

Concurrent logins from a new device cannot create duplicates; unique constraint on (user_id, device_fingerprint).

A :login_new_device event fires exactly once per fingerprint, with IP and user agent metadata for review.

At rest: SHA-256(raw). Over Phoenix Sync streams: SHA-256(SHA-256(raw)). The client cannot reconstruct a usable token from any leak surface.

Single-transaction bulk revocation; LiveView sockets close in real time as their tokens are killed.

MFA enrollment is required before a user can seal. The first seal in a session prompts a fresh TOTP (or one-time backup code); subsequent seals within a 10-minute window pass through. The same gate applies to single-doc and batch seals — one verification authorizes the batch. Every gate outcome (blocked, failed, passed) is recorded in the hash-chained audit log.

Each session's source IP is geolocated; sudden country changes surface in the security event log.

Org admins can cap how many simultaneous sessions a single user may hold; enforced at login.

Device-bound public-key authentication that replaces TOTP for sealing. Phishing-resistant, no shared secret to steal.

Target: passkey enrollment in settings this quarter; sealing-gate integration next.

Re-prompt for MFA or passkey on credential changes, payment method updates, and member-role escalation — not just on sealing.

Flag sessions whose source location moved faster than a commercial flight could explain. Triggers a forced re-auth instead of a hard kick.

Org admins can require a FIDO2 hardware key for any sealing operation, optionally limiting which key vendors are accepted.

Driven by Enterprise customers with existing hardware-key fleets.

Verify a managed device's identity (TPM-backed key on Windows, Secure Enclave on Apple) before granting access.

Periodic background re-checks of session posture (geo, risk score, device trust); inactive sessions auto-tier down.

Push login and session events to your SIEM (Splunk, Datadog, Sumo) over a signed webhook stream.

A SHA-256 of IP + UA is a session-scoped identifier the user can break by clearing cookies. We do not want to know more than that.

Why we rejected it: high-entropy fingerprints cross the line from "is this the same session" to "is this the same person across browsers and incognito." That is tracking, not security. We are a sealing platform; we do not need it.

These cannot be revoked, often cannot be rotated, and survive factory resets. A leaked IMEI is forever.

Why we rejected it: hardware identifiers are an attractive nuisance. They look stable, but they create a permanent record that follows the user forever and creates HIPAA / GDPR risk we do not need.

SS7 attacks, SIM swapping, and carrier-side inspection make SMS the weakest second factor in common use.

Why we rejected it: SMS is broken for security, full stop. NIST has been deprecating SMS-as-second-factor since 2016. We use TOTP today and are moving to passkeys; SMS is not on the path.

A licensed engineer in Texas legitimately travels to a conference in Germany. Hard-blocking on country mismatch generates more support tickets than security wins.

Why we rejected it: we surface geo signals (impossible-travel, sudden country change) but trigger step-up auth, not termination. False positives in security have a cost — we measure it and design around it.

Long-lived MFA bypasses are the most common path to account takeover. We do not offer them, even though competitors do.

Why we rejected it: every "remember me" is a prefilled answer to "did you actually verify the human?" For sealing — a legally significant act — we accept the friction of MFA every time. The friction is the feature.