Prompt and scope
This product question tests how you turn a security control into a tiered experience. The goal is not to make every page ask for a password again; it is to define high-value actions, risk signals, authentication strength, recovery, and measurement.
What the interviewer is assessing
- Whether you can rank action risk by asset value and irreversibility.
- Whether you understand the distinct roles of reauthentication, MFA, device trust, and risk signals.
- Whether you can handle accessibility, cross-device use, enterprise SSO, and account recovery.
- Whether you can evaluate security, success rate, abandonment, and support cost together.
Clarifying questions to ask
Confirm user roles, tenant permissions, reversibility, data sensitivity, enterprise identity-provider capability, current session lifetime, MFA coverage, and recovery channels. Clarify the threat model too: session hijacking, shared devices, insider mistakes, or account takeover after a high-risk login.
A 30-second answer framework
I would build an action-risk matrix: a full-tenant export, MFA change, payment change, or tenant deletion is high risk; viewing a report is low risk. High-risk actions would trigger time-bounded reauthentication, preferably using an existing strong factor or WebAuthn, with stronger requirements after risk events or on a new device. The flow needs a clear reason, accessible alternatives, controlled recovery, and audit events. I would roll it out gradually and measure high-risk blocks, legitimate completion, abandonment, takeover events, and support cost rather than prompt count alone.
Step-by-step solution
1. Define risk by action, not by page
Score actions by blast radius, reversibility, privilege elevation, and data sensitivity. Tenant deletion, personal-data export, changing recovery factors, and granting admin rights belong in the high-risk set; ordinary reads and reversible preferences usually need less friction. Product, security, legal, and support should approve the matrix together.
2. Choose authentication strength and lifetime
High-risk actions can require the primary credential plus MFA, or a phishing-resistant WebAuthn ceremony. The reauthentication assertion should be bound to the user, tenant, action scope, and a short lifetime; it must not become a long-lived pass. Signals such as a new device, unusual location, or completed recovery should shorten the lifetime or raise the requirement, not automatically become the only denial reason.
3. Design an understandable and accessible experience
Explain why verification is needed, what it protects, and what happens after completion. Support keyboard use, screen readers, and alternatives that do not rely on one biometric; enterprise SSO users should return to their identity provider. Do not reveal internal risk rules in error text or trap users in a loop after repeated failures.
4. Plan recovery and exception paths
Lost MFA devices, cross-device approval, account recovery, and enterprise-admin assistance need explicit paths. Recovery itself is high risk, so a weaker backup question must not bypass step-up. Record the reason, notify relevant users, and limit a newly added recovery factor from immediately authorizing sensitive actions.
5. Connect the control to backend authorization and audit
A frontend prompt is not protection. The server must validate the session's reauthentication assertion, action, and tenant scope so it cannot be replayed against another API. Audit events record actor, tenant, action, authentication method, summarized risk signals, and result; logs must not retain secrets or full credentials. Services handling sensitive data still require correctly configured TLS.
6. Validate security and product outcomes in stages
Start with internal tenants and a small percentage of high-risk actions. Observe authentication success, abandonment, recovery, false denials, and support tickets before expanding. Security metrics include blocked high-risk actions, session takeover, and abnormal recovery; experience metrics include completion time, success rate, and repeated prompts. If risk falls while legitimate failures rise, tune action tiers, lifetime, or recovery instead of simply disabling the control.
High-quality sample answer
I would confirm the threat model with security, support, and enterprise admins, then rank actions by blast radius, irreversibility, privilege elevation, and data sensitivity. A full-tenant export, MFA change, payment change, or tenant deletion is high risk, while report viewing stays low friction. High-risk actions trigger a short-lived assertion bound to the user, tenant, and action, preferably through WebAuthn or enterprise MFA; a new device, unusual location, or recent recovery raises the requirement. The UI explains the reason and supports keyboard, screen-reader, and enterprise-IdP paths, while recovery cannot use a weaker factor to bypass protection. The server validates the assertion and writes an audit event; the frontend cannot authorize by itself. I would launch gradually and monitor high-risk blocks, legitimate success, abandonment, takeover, and support cost, then adjust the matrix and lifetime with evidence.
Common mistakes
- Requiring a fresh login on every page until users bypass or disable the control.
- Showing a reauthentication dialog in the frontend while the API ignores action scope.
- Using SMS or a security question as the only high-risk recovery path without a threat model.
- Omitting enterprise SSO, accessibility, cross-device, or lost-MFA paths.
- Measuring prompt count without takeover, false-denial, completion-time, or support data.
- Writing raw risk signals into user copy or audit logs and exposing detection details.
Follow-up questions and responses
When is one login enough?
Low-risk, reversible, small-blast-radius reads or preferences can reuse the current session. Skipping step-up depends on action risk, session state, and organizational policy; “the user is already logged in” is not sufficient.
Must a new device always block a sensitive action?
No. A new device is a signal to raise assurance, not proof of malicious intent. Require stronger MFA, notify a tenant admin, or shorten the assertion lifetime, then tune with false-denial and takeover data.
How do you prevent replay of a reauthentication assertion?
Bind it on the server to the user, tenant, action, resource, and short time window, then consume or rotate it after a successful operation. A generic “verified” flag must not authorize every sensitive API.
What if the user cannot complete MFA?
Offer an audited recovery path such as enterprise-admin assistance or another strong factor, with notifications and a cooling period. Recovery itself must not directly bypass high-risk action protection.