Customer registration forms are usually designed by growth teams for conversion, yet every field they add is personal data to protect and every field they remove is a signal the fraud team no longer has. Upfront registration collects the full profile before the account exists; progressive profiling creates the account with the minimum and asks for more later, when a feature or transaction needs it. The choice decides how much data you hold on accounts that never transact, how easily bots can mint accounts, and when you prove who someone is. This guide compares the two patterns on data minimisation, fake account risk, identity proofing, consent capture and the trade between conversion and assurance, then gives a decision method and a worked design. It is for CIAM architects, product security leads and privacy engineers. For platform basics, see the Customer IAM (CIAM) Guide.
Key takeaways
- Progressive profiling is the default that GDPR points to. Article 25(2) requires that, by default, only personal data necessary for each specific purpose is processed, and the ICO says you must not collect data "on the off-chance that it might be useful in the future".
- Thin sign-up is not the same as weak sign-up. The fraud defence at registration comes mostly from passive signals (device, network, velocity, email and phone reputation), not from extra form fields that a bot fills in as easily as a person.
- Tie each attribute and each proofing step to a trigger. Ask for a delivery address at first order, a verified phone before stored-value features, and identity proofing before the transaction that carries the risk, mapped to an assurance level.
- Consent is collected at the moment of purpose. Progressive flows fit GDPR consent rules well, because each request can be specific and unbundled, but they multiply the consent events you must record and be able to demonstrate.
- Upfront registration still wins in regulated onboarding. Where the law or the product requires a verified identity before any service (account opening for a regulated financial product, for example), collect and proof first, and minimise what you keep afterwards.
Short answer
Use progressive profiling for most consumer services: create the account with an identifier and a credential (ideally a passkey), score the sign-up for automation and abuse, and collect further attributes and identity evidence only when a feature needs them. Use upfront registration when a verified identity is a precondition of the service, when the first action after sign-up already carries high fraud or safety risk, or when a regulated onboarding process prescribes the data. In both cases the identity assurance level should follow the risk of the action, not the stage of the form.
| Dimension | Upfront registration | Progressive profiling |
|---|---|---|
| What is collected at sign-up | Full profile: name, contact details, address, date of birth, preferences, sometimes identity evidence | Identifier and credential; everything else deferred to a trigger |
| Data held on dormant accounts | Full profile for every account, including the many that never transact | Minimal; richer profiles only for active users who needed them |
| GDPR fit | Must justify each field as necessary at sign-up (Art. 5(1)(c), Art. 25(2)) | Aligns naturally with necessity per purpose; needs per-step notice and records |
| Fake account friction | More fields slow humans; scripted bots fill them at no cost | Little form friction; relies on passive risk signals and later gates |
| Identity proofing | Possible before any access; one-time cost for every applicant | Step-up proofing at the risky transaction; cost only for those who reach it |
| Consent capture | Risk of bundled consents on one long form | Specific consent at the point of purpose; more consent events to log |
| Data quality | Users invent values to get through long forms | Values requested when the user has a reason to give accurate data |
| Engineering complexity | Simple, single flow | Profile state machine, triggers, partial-profile handling across apps and APIs |
Data minimisation: what the law actually asks
GDPR Article 5(1)(c) requires personal data to be "adequate, relevant and limited to what is necessary" for the purposes, and Article 25 requires data protection by design and by default. Article 25(2) is the clause that bites on registration design: by default only data necessary for each specific purpose is processed, covering the amount collected, the extent of processing, the storage period and accessibility. The ICO's guidance turns this into three tests (adequate, relevant, limited) and adds a periodic review duty: delete what you no longer need.
Upfront forms tend to fail on two points. First, purpose: "we might personalise later" is not a purpose for collecting date of birth on day one. Second, storage: a full profile kept on an account that never activated is held for no current purpose, which also engages storage limitation in Article 5(1)(e). Progressive profiling solves the collection problem by design, but only if the triggers are real. A "complete your profile" nag on every login that asks for fields no feature uses is upfront registration spread over five screens.
Field-by-field necessity
| Attribute | Typical genuine trigger | Collect at sign-up? |
|---|---|---|
| Email or phone (identifier) | Account creation, recovery, notices | Yes, one of them, verified |
| Display name | First social or community feature | Only if the product is social from day one |
| Postal address | First physical delivery or billing that needs it | No |
| Date of birth | Age-restricted feature or legal age check | Only if the whole service is age restricted; consider an age assertion rather than full date |
| Payment details | First purchase or subscription | No, unless the trial requires it |
| Government ID or document evidence | Regulated product, high-value transaction, payout | Only for regulated onboarding |
| Marketing preferences | Separate consent request | Offer, never require, never pre-tick |
For the full method of field reviews, see Data Minimisation.
Fraud and fake account risk
OWASP's automated threats catalogue names the abuse directly: OAT-019 Account Creation, "Create multiple accounts for subsequent misuse", including bulk use of sign-up processes and sometimes profile population, for spam, money and goods laundering and other misuse. The intuitive response, adding mandatory fields, mostly hurts real users. A script fills a twelve-field form as easily as a two-field form, and synthetic or stolen identity data is cheap. What raises attacker cost is signal quality and gating.
Threat model for each pattern
- Upfront registration: the attacker supplies plausible fake or stolen attributes, so the form gives false confidence; the organisation then stores fabricated or stolen personal data, sometimes belonging to real third parties. If proofing is upfront, attackers target the proofing step itself with forged documents or injected media, but each attempt costs them.
- Progressive profiling: account creation is cheap, so bulk creation is easier unless passive controls catch it. The risk moves to the first valuable action: promotion redemption, posting, messaging, payouts, referral credits. If those actions are not gated by a trigger, a thin account is a ready-made abuse vehicle.
- Both: account takeover of established accounts bypasses sign-up controls entirely, and a richer stored profile raises the impact. The 23andMe breach showed how profile data shared between accounts let credential stuffing on about 18,000 accounts expose information on almost 7 million people.
Controls that work with a thin sign-up
- Passive risk scoring at sign-up: device and browser signals, IP reputation and velocity, disposable email domains, phone line type, and form interaction timing. See the Fake Account Creation and Sign-up Fraud Guide.
- Adaptive challenge: show a bot challenge only to risky sessions rather than to everyone. See CAPTCHA and bot challenges.
- Verified identifier: confirm control of the email or phone before the account can do anything valuable.
- Capability gating: new accounts start with limited capabilities; posting limits, payout holds, referral credit only after a verified purchase.
- Rate limits on the sign-up endpoint and API: per IP, device and identifier pattern; the OWASP entry cross-references CWE 799 (Improper Control of Interaction Frequency).
- Re-score at each trigger: every profile step is a new data point; a mismatch between claimed country, payment card country and network location is more useful at first purchase than at sign-up.
When to step up identity proofing
NIST SP 800-63-4 (the 2025 revision, which supersedes SP 800-63-3) treats identity proofing as a risk decision. It says identity proofing is not required if the online service does not need any personal information, and that a service may skip proofing where the potential harms from accepting self-asserted attributes are insignificant. When proofing is needed, the initial identity assurance level maps from impact: low to IAL1, moderate to IAL2, high to IAL3. The guidelines also allow partitioning a service so that less sensitive functions are available at a lower assurance level. That partitioning is exactly what progressive profiling with step-up proofing implements.
| Trigger | Example | Assurance step |
|---|---|---|
| Browse, save, low-value purchase | Retail account, newsletter | No identity proofing; verified identifier; self-asserted attributes |
| Stored value, credit or payouts | Wallet top-up, marketplace seller payouts | Verified phone, payment instrument checks; IAL1 or IAL2 by impact |
| Access to sensitive personal data | Health records, children's data, genetic data | IAL2 proofing plus phishing-resistant authentication |
| Regulated product or legal age requirement | Financial account opening, age-restricted goods | Proofing as the regulation prescribes, before the service starts (upfront for that product) |
NIST SP 800-63A-4 also builds minimisation into proofing: collect the minimum evidence and attributes needed, request additional attributes only after a privacy risk assessment, and tell applicants which attributes are voluntary and which are mandatory. Do not keep document images longer than the purpose needs. For the proofing levels in depth, see the NIST SP 800-63A-4 Identity Proofing (IAL) Guide and the Identity Proofing and KYC Guide.
Keep authentication assurance separate from proofing. Step-up for a sensitive action may need a stronger authenticator (SP 800-63B-4 defines AAL2 as two distinct factors with a phishing-resistant option available, and AAL3 as a phishing-resistant cryptographic authenticator with a non-exportable key) without any new proofing. See the OAuth Step-Up Authentication Challenge Guide.
Consent capture
Where processing relies on consent, GDPR Article 7 requires the controller to be able to demonstrate it, the request to be clearly distinguishable from other matters, withdrawal to be as easy as giving it, and Article 7(4) asks whether a service is made conditional on consent to processing not necessary for it. The ICO adds that consent should be unbundled from terms and conditions, that pre-ticked boxes are not consent, and that granular options are needed for separate purposes.
- Upfront risk: a single sign-up form invites a bundle of terms, marketing, profiling and partner sharing, often with defaults set. That bundle is the pattern the ICO lists as a sign of invalid consent.
- Progressive advantage: each request appears when the purpose is real (location for store finder, marketing when the user opts into offers), so it is specific and informed.
- Progressive cost: you now hold many consent events per user across apps and channels. Record what was shown (notice version), the choice, timestamp, channel and the identity it applies to, and make withdrawal available in the same place.
- Lawful basis discipline: attributes needed to deliver an order rest on contract, not consent; do not ask for consent where it is not the basis, and do not quietly reuse a contract-basis field for marketing.
See the Identity Data Privacy and Consent Guide and the Consent Management Guide: Cookies, CMPs and GPC.
Conversion versus assurance
The real trade-off is not short form versus long form; it is where friction sits. Upfront registration charges every visitor the full cost of assurance before any value is delivered. Progressive profiling charges only those who reach a risky step, at the moment they have a reason to accept it. Security teams sometimes resist progressive flows because thin accounts look unverifiable. The answer is to define, per capability, what assurance it needs and to enforce that in the authorisation layer, so a thin account simply cannot do the risky thing yet.
Architecture in words
- Profile state: the CIAM store holds attribute values plus their provenance (self-asserted, verified, proofed at IAL) and verification date.
- Capability policy: each capability declares required attributes and assurance, for example "payout requires verified phone, IAL2, AAL2".
- Trigger and step-up: when a request fails the policy, the application or orchestration layer runs the missing step and resumes the original action. See the Identity Orchestration Guide.
- Token claims: issue claims such as assurance level or verified-attribute flags, never raw sensitive attributes, to downstream APIs.
- Retention: delete or downgrade attributes when the capability that needed them is no longer used.
Decision criteria
- Is a verified identity a legal precondition? If yes, use upfront registration for that product, with proofing first and minimised retention after.
- What is the first valuable action? If it carries financial or safety risk within minutes of sign-up (instant credit, messaging minors, payouts), either gate it by trigger or move the checks upfront.
- Can your platform hold partial profiles safely? Every app and API must cope with missing attributes; if they assume a full profile, fix that before shipping progressive flows.
- How strong are your passive signals? Progressive sign-up depends on risk scoring; without it, add adaptive challenges before thinning the form.
- Can you record consent per event? If not, progressive consent becomes undemonstrable.
Small organisations: start with identifier plus passkey or verified email, collect address and payment at checkout, and use the CIAM platform's built-in bot protection. Large organisations: a capability policy model, central consent ledger, per-trigger fraud scoring and attribute retention rules across brands. See B2B vs B2C CIAM where business customers change the picture.
Worked scenario
An online marketplace asks for name, address, date of birth, phone and marketing consents at sign-up, and lets new sellers list immediately. It sees fake seller accounts with plausible details and a growing store of profile data on accounts that never trade.
- Sign-up: reduced to email plus passkey, with passive risk scoring and a challenge for risky sessions. Marketing consent moves to a separate, optional prompt.
- First purchase: delivery address and payment collected at checkout, under contract, with card and address risk checks.
- Becoming a seller: verified phone and identity proofing at the level the payout risk requires; payouts held until proofing completes.
- Age-restricted category: age check only when a buyer enters that category.
- Retention: accounts with no activity are purged on a schedule; proofing evidence kept only as long as the stated purpose requires.
Result: fewer fields held for dormant accounts, fake sellers stopped at the payout gate where proofing actually costs the attacker, and consent records that match purposes.
Detection and measurement
| Metric | What it shows |
|---|---|
| Share of accounts holding attributes no active capability uses | Whether minimisation is real or a "complete your profile" nag |
| Fake or abusive accounts detected per 1,000 sign-ups, and the stage they were caught | Whether controls catch abuse before the first valuable action |
| Step-up completion rate per trigger | Friction cost of each assurance step |
| Abuse losses on accounts younger than 30 days | Whether capability gating is effective |
| Consent events with a complete record (notice version, choice, time, channel) | Ability to demonstrate consent under Art. 7(1) |
Log sign-up risk scores and decisions, every trigger and step-up outcome, proofing results (not raw evidence), and consent events, with the account identifier, so fraud and privacy teams work from the same timeline.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| GDPR | Art. 5(1)(b), (c), (e); Art. 7; Art. 25 | Purpose limitation, minimisation, storage limitation, consent, data protection by default |
| NIST SP 800-63-4 suite | SP 800-63 (IAL selection), 800-63A-4 (proofing, minimisation), 800-63B-4 (AAL) | When to proof, at which level, and step-up authentication |
| NIST SP 800-53 Rev. 5 | PT-2 Authority to Process Personally Identifiable Information; PT-4 Consent; SA-8(33) Minimization; IA-12 Identity Proofing | Privacy and proofing controls behind each trigger |
| OWASP Automated Threats | OAT-019 Account Creation | Fake account threat at sign-up |
Common failure patterns
- Progressive in name only: repeated prompts for fields that no feature uses, so the organisation collects the same data as before, just later.
- Thin sign-up with no gates: accounts can redeem promotions, message other users or receive payouts before any trigger runs.
- Self-asserted treated as verified: a typed date of birth or address flows into decisions that assume it was checked; store provenance with each value.
- Bundled consent at sign-up: terms, marketing and partner sharing behind one checkbox, which the ICO lists as invalid.
- Proofing evidence kept forever: document images and selfies retained after the decision, turning the CIAM store into a high-value target.
- Apps assuming a full profile: downstream services break or default silently when attributes are missing.
Practitioner checklist
- List every registration field with its purpose, lawful basis and the capability that needs it; remove or defer the rest.
- Define a capability policy: required attributes, provenance and assurance level per risky action.
- Add passive risk scoring and adaptive challenges to sign-up before thinning the form.
- Gate first valuable actions (payouts, messaging, promotions) behind triggers.
- Map step-up proofing to IAL by impact, using SP 800-63-4, and step-up authentication to AAL separately.
- Unbundle consent, record each event with notice version, and make withdrawal as easy as giving.
- Store attribute provenance and verification dates; issue assurance claims, not raw attributes, to APIs.
- Set retention for dormant accounts and proofing evidence, and review it periodically.
Standards and references
- GDPR: Article 25, data protection by design and by default
- GDPR: Article 5, principles relating to processing of personal data
- GDPR: Article 7, conditions for consent
- ICO: Principle (c), data minimisation
- ICO: What is valid consent?
- NIST: SP 800-63-4 Digital Identity Guidelines
- NIST: SP 800-63A-4 Identity Proofing and Enrollment
- OWASP: OAT-019 Account Creation
Related NHI Mgmt Group resources: Customer IAM (CIAM) Guide · Fake Account Creation and Sign-up Fraud Guide · Identity Proofing and KYC Guide · CIAM Buyer's Guide · Rogue Device Registration