Polyester uses multi-factor authentication to protect interactive account access and high-risk actions.
MFA is not treated as one global switch. Polyester separates normal login, elevated sessions, and fresh step-up checks so everyday account use stays smooth while sensitive actions get stronger proof.
Use passkeys when available. They are faster for most users and more resistant to phishing than one-time codes.
Supported factors
Polyester supports three MFA building blocks:
Factor | Role | Best for |
|---|---|---|
Passkeys preferred | Phishing-resistant authentication backed by the user's device or hardware key. | Most users and high-risk actions |
TOTP | Six-digit time-based codes from an authenticator app. | Broad compatibility |
Recovery codes | Backup credentials for account recovery. | Emergency access if a primary factor is unavailable |
Passkeys are generally the strongest day-to-day option. TOTP remains useful because it is widely understood and works across many devices.
Session assurance model
Polyester uses explicit assurance levels instead of a single "MFA complete" state.
Level | What it means | Typical use |
|---|---|---|
Primary session | The user completed normal login. | Routine authenticated activity |
MFA-elevated session | The user completed MFA during the current session. | Account security workflows and smoother post-MFA navigation |
Fresh step-up | The user completed MFA again for one specific high-risk action. | Withdrawals, security changes, whitelist changes |
A previous MFA event is not always enough. For high-risk mutations, Polyester can ask the user to complete MFA again immediately before the action is accepted.
Factor comparison
Passkeys use the browser or operating system's WebAuthn support and are backed by secure device credentials.
Benefits:
resistant to common phishing flows
fast on modern devices
no code entry
works well with Face ID, Touch ID, Windows Hello, laptop PINs, and hardware security keys
Trade-offs:
requires compatible browser and device support
relies on correct origin and relying-party configuration
TOTP is the familiar six-digit code generated by an authenticator app.
Benefits:
widely supported
easy to understand
works across many devices
useful as a compatibility fallback
Trade-offs:
users must manually read and enter a code
codes can be phished if a user enters them into a malicious site
Recovery codes are backup credentials shown when a factor is enrolled or recovery codes are rotated.
Good practice:
store them offline or in a secure password manager
treat them as sensitive credentials
rotate them if compromise is suspected
use them only for recovery, not day-to-day authentication
Why this model exists
If a platform only distinguishes between "logged in" and "MFA enabled", it usually ends up in one of two bad states:
MFA prompts happen too often and degrade UX
MFA prompts happen too rarely and weaken security
The assurance model avoids that trade-off:
routine account activity can stay smooth
sensitive actions get stronger verification
passkeys can make extra verification fast and low-friction
high-risk handlers can re-check fresh proof before accepting the action
High-risk actions
Fresh step-up is used for actions that materially change account security or move value.
Examples include:
Action | Why it is sensitive |
|---|---|
Creating an API key | Adds new programmatic access to the account |
Changing API key permissions | Can expand what automated systems are allowed to do |
Relaxing API key IP restrictions | Reduces network-level protection |
Deleting an MFA factor | Weakens the account's future authentication posture |
Regenerating recovery codes | Changes emergency account recovery material |
Withdrawals and untrusted transfers | Moves value out of a trusted account boundary |
Changing destination whitelists | Changes where future value can move with fewer prompts |
These are the kinds of actions where "the user is logged in" is not enough by itself.
See Withdrawals and Transfers Security for the money-movement model.
How MFA fits with wallet signatures
MFA and wallet signatures protect different parts of the risk model.
Proof | Protects against | Example |
|---|---|---|
MFA | Stolen session or unattended browser access | User confirms a withdrawal with a fresh passkey prompt |
Wallet signature | Unauthorized transfer intent mutation | User signs exact asset, amount, source, destination, nonce, and expiry |
Whitelist | Repeated transfers to trusted destinations | User sends to a previously trusted address with reduced friction |
For the highest-risk flows, Polyester can combine these controls. A stolen session alone is not enough to move funds to a new destination.
Practical summary
Polyester MFA includes:
passkeys for phishing-resistant authentication
TOTP for broad compatibility
recovery codes for emergency access
MFA-elevated sessions for smoother account security workflows
fresh step-up for high-risk actions
In short:
Passkeys are the preferred factor when available
TOTP is the traditional compatibility path
Recovery codes are a backup, not a daily login method
Fresh step-up protects actions that matter most