Direct answer
I weigh the security benefit against the friction a customer will actually feel, using numbers where I can. Then I look for the lowest-friction way to get most of the protection, and I roll it out in stages with measurements and an exit. Security wins when the risk is serious and not otherwise reducible, but how it ships is a customer-experience decision.
How I weigh it
- Risk removed. What attack or loss does the change prevent, how likely, and for whom? Ask security for a specific scenario, not "best practice."
- Friction added. Which customers feel it, how often, at what moment (signing in daily versus a rare admin action), and what do they do when annoyed (abandon, call support, work around it)?
- Cheaper routes to the same protection. Apply the strict control only where risk is high (risk-based or step-up checks: ask for an extra proof only when something looks unusual or the action is sensitive), remember trusted devices, or give a smoother factor.
- Who carries the cost. Friction on a signup flow costs conversion; friction in an enterprise admin flow costs support calls.
Three related cases
| Case | The tension | What I would do |
|---|
| Multi-factor authentication (MFA, a second proof of identity at sign-in) | Fewer account takeovers but setup drop-off and more lockout-related support contacts (people locked out of their account who then contact support) | Offer easier factors, remember trusted devices, ask for MFA on sensitive actions first, provide clear recovery, and plan support staffing for launch |
| Encryption that adds latency for latency-sensitive customers | Stronger protection versus slower responses for customers whose use depends on speed | Measure added delay at the 95th percentile (P95: the response time that 95% of requests beat, which shows the slow tail that averages hide) on their real paths, optimize before shipping, keep the protection that is required, and discuss any customer-specific option with security rather than silently weakening it |
| Social login (sign in with another provider's account) | Higher signup conversion versus sharing data with a third party and tying account recovery to it | Offer it next to email sign-in, request only needed data, state plainly what is shared, and test conversion against trust |
Worked example (illustrative): rolling out MFA to 100,000 accounts
- Stage 1: 5% of accounts (5,000), chosen to include small and large customers. Track setup completion, lockout-related support contacts, and sign-in success.
- Gate: advance only if the thresholds agreed beforehand with security and support are met. Illustrative thresholds: at least 80% of prompted accounts finish setup (4,000 of the 5,000), no more than 10 lockout-related support contacts a week (2 per 1,000 accounts), and sign-in success falls by no more than 1 percentage point. Miss any one and I pause, fix the cause, and rerun the stage.
- Stage 2 and 3: widen, with in-app explanation of why, then move from encouraged to required on a published date. Keep a rollback and an exception path for customers with real blockers.
Pitfalls
Do not frame it as security versus customers. Do not roll out to everyone at once. Do not set a "will not hurt conversion" bar with no measurement behind it.
