Multi-factor, as policy.
Enforce multi-factor verification as policy rather than per-controller code, then selectively exempt specific users, operations, or trusted networks. The second factor is required where the risk is, and out of the way where it is not.
1. Why a second factor, and why as policy
Passwords and even API keys are single points of failure: once captured, they grant access. A second factor breaks that by requiring proof the attacker is unlikely to also hold. The harder problem is where to require it. Hard-coding MFA checks into individual controllers guarantees inconsistency — the one sensitive action someone forgot to wrap. Treating MFA as policy makes the requirement uniform and the exemptions deliberate.
2. Risk-based, not friction-for-all
MFA imposed everywhere trains users to click through it; MFA imposed nowhere is no control at all. The right posture is risk-based: require step-up verification for high-risk operations — changing payout details, elevating privileges, exporting data — while exempting low-risk actions, trusted networks, or service identities where a second human factor is meaningless. The friction goes where the risk is.
3. Deliberate, auditable exemptions
Exemptions are where policy controls either succeed or fail. B5 Secure lets specific users, operations, or networks be exempted explicitly, so every gap is a recorded decision rather than an oversight — the inverse of the “internal-only switch” that attackers hunt for.
4. How B5 Secure handles it
B5 Secure enforces multi-factor verification as a configurable stage in the request pipeline, with exemptions expressed as policy rather than buried in handlers. The result is a system where the second factor is present on every path that needs it, absent where it would only add friction, and auditable everywhere — consistent with verifying every request and granting least privilege.