MFA and sensitive operations

Mandatory MFA on destructive actions

Multi-factor authentication (MFA) is not merely encouraged at sign-in: it is mandatory to trigger a destructive action. Revoking a member, disabling the network lock, deleting a network — those gestures that cannot be undone require a second factor, not just an already-open session.

The reasoning is least privilege over time: a session may have been left open, a workstation momentarily accessible. Requiring the second factor at the precise moment of the destructive action brings the proof of identity back to the instant of danger, not to the sometimes distant moment of sign-in.

Sudo re-authentication

Beyond MFA, the most critical operations trigger a "sudo" re-authentication: right before execution, the system asks you to prove your identity again, just as the sudo command asks for a password again before a privileged action. The proof of identity is thus fresh, tied to the precise operation you are about to launch.

Concretely, this closes the window where an open session would suffice: even authenticated, even with an MFA validated earlier, you must confirm again at the moment of acting. This elevation is short-lived and scoped to the operation at hand — it does not grant a blank cheque for the rest of the session.

API keys: hashed and scoped

API keys are treated as secrets, not as ordinary identifiers. They are stored hashed: the server keeps a fingerprint that lets it verify a presented key, never the key in the clear. A database leak therefore yields no keys usable as-is.

They are also scoped: each key carries a perimeter of rights limited to what it needs, rather than full access. A compromised key then only exposes the scope it was granted. It is the same least-privilege logic as for destructive actions, applied to automated access.

• Hashed storage: the key is visible in the clear only once, at creation — store it somewhere safe immediately.
• Restricted scope: grant each key only the rights strictly necessary for its use.
• Lifecycle: revoke without delay any key that is no longer used or that you have doubts about.

Traceability

These protections are only worth having if you can verify, after the fact, who did what. Sensitive actions leave a reviewable trace: the audit console, described on /en/docs/console-audit, lets you track critical operations, revocations and privilege elevations. Prevention requires a second factor; traceability provides the proof.