Critical Actions: Why Some Operations Ask for Both Devices Again

You are logged in. You have an admin role. You click "remove member" — and SSP asks you to sign with both of your devices, exactly as though you were logging in from scratch.

This is not friction for its own sake. It is a deliberate line drawn between operations a session token should be able to authorise and operations it should not, and the reasoning behind that line is worth understanding whether or not you use SSP.

Sessions are for convenience, not consequence

A session token is a bearer credential. Whoever holds it is you, as far as the server is concerned. That is precisely what makes sessions convenient — you authenticate once and then act freely — and precisely what makes them a poor basis for irreversible decisions.

Sessions get stolen. Through a cross-site scripting bug, an unlocked laptop, malware, a leaked backup, or simply a browser left open in a shared office. The OWASP session management guidance treats session theft as an expected condition rather than an edge case, and any design that assumes otherwise is optimistic.

For most actions this is an acceptable risk, because most actions are reversible. Renaming a vault, adding a viewer, adjusting a notification setting — if an attacker with a stolen session does these, you undo them.

Some actions are not like that. Transferring ownership of an organisation hands control to someone else. Removing a member cuts off their access. Deleting an organisation is final. For these, SSP requires proof that the person acting still holds both devices right now — not that they held them at some point earlier in the day.

The thirteen actions

Thirteen operations require re-signing. They fall into four groups.

Organisation control

• Transfer ownership
• Delete organisation

Membership and roles

• Remove a member
• Promote a member to admin
• Demote an admin

Account identity

• Change the enterprise email
• Remove the enterprise email

Vault lifecycle and administration

• Archive a vault, and unarchive a vault
• Freeze a vault, and unfreeze a vault
• Promote a vault admin, and demote a vault admin

What unites them is not that they move money — none of them do, and none of them can, because only signers can move funds. What unites them is that they change who can do things afterwards. They are the operations an attacker would want in order to entrench access, lock out the real owners, or quietly prepare for a later theft.

Notably, the email-related actions are in the list. Changing the enterprise email on an account looks administrative, but it is the classic first move in an account takeover: redirect the recovery channel, then work at leisure. Requiring both devices for it closes that path.

Why the server writes the challenge

The mechanism matters as much as the requirement, and one design decision does most of the work.

The server generates the message you sign. The client never does.

If the client composed its own challenge, a compromised client could compose a convenient one — a message describing a harmless action, signed by a user who believed they were doing something harmless, then replayed against a dangerous endpoint. Having the server author the message means the thing you sign is the thing that will be executed, because the server checks the signature against the message it issued and no other.

This is the same pattern SSP uses for login, and the same pattern that makes signature-based authentication safe in general: never sign something you did not receive from the party who will verify it.

What the challenge is bound to

The message is not a generic "yes". It is a specific string containing four things that together make a captured signature useless anywhere else.

The exact action. remove_member and transfer_ownership produce different messages. A signature for one cannot authorise the other.

The exact target. The organisation, the vault where relevant, and the person being acted upon are all named in the message. Vault-scoped actions explicitly include the vault ID so that a signature for freezing one vault cannot be replayed to freeze a different one.

A timestamp. It occupies the first thirteen characters of the message — a fixed position, because SSP Wallet validates that format before displaying anything. Challenges expire after fifteen minutes.

A random nonce. Twelve bytes of cryptographic randomness, making each challenge unique even for an identical action against an identical target at the same second.

And the challenge is single-use. When it is redeemed, the server marks it used in the same atomic operation that validates it — so a replayed signature is rejected with "already used" rather than quietly succeeding twice. Expired challenges are cleaned up automatically by a TTL index.

Every attempt is recorded, including the failures

Critical actions are written to a permanent log, and there is a detail here that is easy to skip past: the log entry is written when the challenge is requested, not only when the action completes.

That means the record includes attempts that were abandoned, attempts where signing failed, and attempts that were refused. A single failed critical action is usually someone changing their mind. A cluster of them at 3am is a story.

Like the rest of SSP's audit trail, these records have no expiry and no cleanup job. The value of an audit log lives entirely in the parts nobody anticipated needing.

What this looks like in practice

Have both devices with you before you start. Critical actions cannot be completed with one device, and the challenge expires in fifteen minutes. If your phone is in another room, fetch it first.

Read the action on your phone, not just the dashboard. The message your devices display names the action and the target. That is your opportunity to notice that the target is not who you expected — the same habit that protects you when reviewing a transaction. Phishing attacks targeting crypto users covers why a second look at the second device is worth the seconds it costs.

Do not batch them. Each critical action gets its own challenge and its own signature. If you are removing three departing employees, that is three signings. This is deliberate — batching would mean one signature authorising several changes, which is exactly the property we are trying to avoid.

Expect them at the worst times. Critical actions cluster around exactly the moments when someone is leaving, an account is compromised, or a vault needs freezing — which is to say, the moments when people are stressed and want to move fast. Knowing in advance that these need both devices turns a surprise into a step.

The broader picture of what enforces what — and why re-signing sits in the middle layer rather than the strongest one — is in what actually stops a transaction. For how the organisation and its vaults fit together, start with SSP Enterprise: multisig vaults for teams.