B2C Authentication Requirements: The Buyer's Checklist

Key takeaways

• In consumer identity the login is a revenue surface before it is a security surface. A platform that reports authentications and not abandonment reports the half that was never at risk.
• Passkeys as a second factor keep the password, and the password is the credential being attacked. Require passkeys as a primary credential with autofill.
• Whoever controls the enrollment prompt controls your passkey adoption curve. Require control of timing, eligibility, and dismissal, with events per ceremony stage.
• Enumerate every path back into an account, including support-mediated ones. The weakest is your real security ceiling.
• SMS is a cash cost and a fraud target. Require per-country controls and ask who absorbs the bill for pumped traffic.
• Cost failures are almost never the unit price. They are the billable-unit definition and the feature that changes tier.

What changes when the users are consumers

The format is the same as the B2B requirements list: a stable ID, a priority, and an acceptance test you run rather than a question you ask. MUST means walk away if unmet. SHOULD means negotiate, or plan to build the gap yourself and price that into the comparison. The RFP builder generates a document from any selection of these IDs.

Registration and login experience

Every additional step at signup costs completions, and the data collected in that moment is the data you are least entitled to and least likely to need. These requirements are about measuring the loss and then reducing it, which makes them the only requirements in this document that a growth team will care about as much as a security team.

ID	Requirement	Priority
REG-01	Registration and login measurable as a funnel per step, device class, and channel, with exportable events	MUST
REG-02	Progressive profiling: minimum at signup, enrichment later, without a second account	SHOULD
REG-03	Hosted flows brandable and served on your own custom domain	MUST
REG-04	Social providers configurable with deterministic linking rules, never silently merging on email match	MUST
REG-05	Flows localizable including error text, message templates, and right-to-left layouts	SHOULD

REG-01 is the requirement that makes every other conversation possible. Without per-step events you cannot say what the password field costs you, cannot justify a passwordless rollout, and cannot tell a regression from a seasonal dip. Confirm that events exist for step entry, step completion, and abandonment, not only for authentication success and failure. The wider argument for instrumenting the funnel before renegotiating the bill is in The Identity Tax.

REG-03 is not a branding preference. A vendor domain in the address bar at the moment of authentication costs conversion, trains users to accept redirects to unfamiliar hosts, and complicates password-manager continuity. It also determines your passkey relying-party identifier, which is the detail that makes it an exit requirement as well as an experience one. Check which of the certificate, the cookie scope, and the RP ID actually follow the custom domain, because they do not always move together.

REG-04 is where consumer products quietly corrupt their user table. Consumers re-authenticate with whichever button they remember, so the same human arrives through a password one week and a social provider the next. Without explicit, verification-driven linking rules, one human becomes two accounts or, far worse, two humans become one record that cannot be unpicked afterwards.

Authentication factors

The factor mix decides both the phishing resistance of the account and the friction of reaching it. The requirements that matter are less about which factors are on the list and more about how much control you keep over when each one is offered.

ID	Requirement	Priority
FACTOR-01	Passkeys supported as a primary credential with conditional UI, not only as a second factor	MUST
FACTOR-02	You control enrollment prompting: timing, eligibility, dismissal, with events per ceremony stage	SHOULD
FACTOR-03	Step-up authentication available at sensitive actions, not only at login	SHOULD
FACTOR-04	SMS one-time codes supported but not required, with per-country controls and pumping protection	SHOULD
FACTOR-05	Factor policy settable per user segment or risk level rather than globally	SHOULD

FACTOR-01 has a precise test: can an account exist with no password at all. Many platforms that advertise passkeys implement them as an additional factor layered on a password, which retains the credential being attacked and delivers neither the security nor the conversion benefit. Verify autofill-driven sign-in on your real device and browser mix rather than on a demo page. Background in passkeys explained.

FACTOR-02 is the most commonly missed requirement in consumer identity. Enrollment rate is set by prompt timing more than by any other variable, so a platform that owns the prompt owns your adoption curve. Confirm you can suppress, defer, and re-offer it, and that prompt-shown, ceremony-started, completed, and abandoned are separately observable. A platform reporting only completed enrollments is hiding the step where users actually leave.

FACTOR-04 is a finance requirement wearing a security costume. SMS is a direct cash cost and an active fraud target, and an attacker cycling registrations against premium-rate ranges bills you for the privilege. Ask for per-country enablement, velocity limits per number and per IP, and a clear answer about who absorbs the cost of fraudulent sends. That last part is usually you.

Account recovery

Recovery is the flow that sets the real security ceiling of every account on the platform, and it is routinely evaluated last or not at all. The right mental model is that effective security equals the strength of the weakest reachable path back into the account, including the paths your own support organization can take.

ID	Requirement	Priority
RECOV-01	Mechanisms at least as strong as the primary credential, including second passkey and recovery codes	MUST
RECOV-02	Recovery initiation notifies every registered channel, with a cancel path	SHOULD
RECOV-03	Configurable cooling period on high-risk recovery, with the original credential still working during it	SHOULD
RECOV-04	Agent-assisted recovery follows the same verification, notification, and delay, fully audit-logged	SHOULD

The test for RECOV-01 is an enumeration rather than a feature check. List every path back into an account, rank them by what an attacker needs, and read off the weakest. A passkey account that recovers by email magic link is structurally an email-secured account, no matter what the login screen shows.

RECOV-02 exists because notifying only the channel being recovered against notifies the attacker when the attacker controls that channel. The legitimate user is usually still reachable somewhere else, and that is the whole value of the notification.

RECOV-04 covers the vector with no technical component at all. Ask what a support agent can do unilaterally, because any action that skips verification, notification, or delay is the path an attacker will take, and help-desk social engineering has been the entry point for several of the most expensive intrusions of recent years. Full treatment in account recovery design.

Abuse and fraud defense

Registration abuse, credential stuffing, and recovery probing are three different attacks with three different signatures. A single global threshold cannot be correct for all three, which is why the tunability requirement matters more than the presence of a defense at all.

ID	Requirement	Priority
ABUSE-01	Bot, stuffing, and brute-force defenses apply to registration, login, and recovery independently and tunably	MUST
ABUSE-02	Breached-credential detection at password set and at login	SHOULD
ABUSE-03	Suspicious-activity signals exposed to you as events, not only acted on internally	SHOULD

ABUSE-02 needs the second half to be useful. Checking only at registration leaves every existing user sitting on a credential that entered a breach corpus afterwards, which is exactly where the exposure accumulates. Confirm the behaviour at both moments, and confirm what is transmitted to the checking service while you are there.

ABUSE-03 is about not buying a black box. Your fraud and detection teams need identity signals joined against everything else they hold, and a risk engine that emits only allow or deny sits inside your funnel making decisions you cannot audit or improve. See bot defense.

Scale, latency, and cost behaviour

Authentication sits in front of everything, so its latency is added to every first page view and its downtime is indistinguishable from your product being down. The cost requirements belong in the same section because at consumer volume the two are the same conversation.

ID	Requirement	Priority
SCALE-01	Published p95 and p99 latency targets per region, plus an availability SLA with remedies	MUST
SCALE-02	Behaviour under attack-shaped load documented, not only clean load	SHOULD
SCALE-03	Cost modelled at three-year volume, including the billable-unit definition and tier gates	MUST

SCALE-02 is the requirement that anticipates a bad week. Capacity planning against well-formed traffic says nothing about the day a stuffing campaign arrives, which is precisely when authentication has to keep working for legitimate users. Ask for twelve months of incident history and post-mortems, and read what happened to legitimate traffic during mitigation rather than how fast the attack was stopped.

SCALE-03 fails on definitions, not on rates. Monthly active user counting differs enough between vendors that identical traffic produces materially different invoices. Get the counting rule in writing, then ask two specific questions: what does one user authenticating on three devices in a month cost, and how is a bot-driven registration spike billed. The second question has an uncomfortable answer at most vendors, and it is better heard before signature.

Privacy, audit, security, and exit

These carry over from the B2B list without modification, because the obligations do not change with the segment. Consumer scale changes only the volume of the problem and the number of people affected when it goes wrong.

ID	Requirement	Priority
PRIV-01	Provider-agnostic enumeration of every subject linked to one user	MUST
PRIV-02	Vendor-side deletion callable from your workflow, confirming completion	MUST
PRIV-03	Residency or region controls stated, with sub-processor change notification	SHOULD
AUDIT-02	Failures observable and alertable, including a connection or integration going quiet	MUST
AUDIT-03	Audit export with retention stated in days for the tier you are buying	SHOULD
SEC-01	Current SOC 2 Type II report and a signable DPA	MUST
SEC-02	Encryption at rest and in transit, documented key management and password hashing	MUST
SEC-04	Documented API rate limits, including the process for raising them	MUST
EXIT-01	Password hashes exportable with algorithm, parameters, encoding, and a contract clause	MUST
EXIT-02	Users and configuration exportable as data	SHOULD
EXIT-03	Passkey portability: RP ID stability under your control, credential record export	SHOULD

Two of these deserve consumer-specific emphasis.

PRIV-01 is harder at consumer scale because one human accumulates more linked subjects: a password identity, several social providers, maybe a wallet. An erasure request covers all of them, and an API that answers one provider at a time makes completeness impossible to evidence.

EXIT-03 is the requirement that becomes load-bearing once passkey adoption is real. A passkey is cryptographically scoped to the relying-party identifier it was created against. If your login lives on a vendor-owned domain, every passkey your users enrolled is invalidated the day you migrate, regardless of any export the vendor offers. That is a direct consequence of REG-03, and it is why the custom-domain requirement is worth marking MUST rather than SHOULD. The mechanics are in password hash migration.

Using this list

Select, do not send wholesale. Every line you include is a line you have committed to testing, and a padded requirements list produces a padded response that is harder to compare than a short honest one.

A reasonable consumer starting point is the MUST rows from registration, factors, recovery, abuse, scale, privacy, security, and exit, with the SHOULD rows added where they match a real constraint you already have. Generate the document with the RFP builder, then run the shortlist through the proof of concept script, dropping its directory-sync tests and spending that time on conversion and abuse instead. If you sell a business tier as well, the enterprise half is in B2B authentication requirements.