2FA before any admin mutation

Routine read views had lower friction than write operations. Writing — creating, modifying, reconfiguring — required a second factor.

The rule is simple: login proves who you are; 2FA before a mutation proves you meant to do it right now.

These are different guarantees.

Adding a second factor on writes means a stolen session is not enough, on its own, to cause a destructive change — that step also needs a device the attacker does not have.

Why even for a solo operator

The counterargument I hear most often: "it is just me, I know what I am doing."

That is true until it is not. The threat model for a solo operator is not a colleague going rogue. It is:

• a compromised browser session from a public computer;
• a phished credential;
• an accidentally opened admin link from a logged-in device someone else is using.

None of these require an adversary. They require one moment of inattention.

A TOTP prompt before a write is not a workflow cost. It is a pause that forces the question: did I actually navigate here intentionally?

What it protects in practice

The dividing line is blast radius, not convenience. Operations that are irreversible, or that change the live product for everyone, sit behind the second factor; routine low-risk reads keep lighter friction. The friction matches the risk — not the workflow.

The point is the rule, not the inventory: decide which class an operation belongs to by what it can break, and protect the destructive class differently from the readable one.

Part of my security and operations notes. Follow the blog or contact me.