Forced action · European Union
Forced registration
The label “Forced registration” describes this recurring design mechanism: the user must create an account, or is led to believe one is required, to complete a goal that could plausibly be provided without it. It is a design and research taxonomy, not a standalone legal conclusion. Depending on the complete journey and likely effect, current EU consumer or sector rules may require separate assessment. No published Digital Fairness Act proposal currently creates a pattern-specific prohibition or duty under this label.
- Family
- Forced action
- Also known as
- Journey stages
Definition
What is this pattern?
The user must create an account, or is led to believe one is required, to complete a goal that could plausibly be provided without it. The label describes a recurring design mechanism; whether a particular implementation is harmful or unlawful depends on the complete journey, audience, evidence and rules within scope.
How it works
The user must create an account, or is led to believe one is required, to complete a goal that could plausibly be provided without it. The gate converts an otherwise available task into account creation, so the user must create a persistent identity record before reaching the requested outcome.
Warning signs
- A desired goal is gated by account creation.
- No equivalent guest or bypass route is available or discoverable.
- Registration is not evidently necessary for the specific function.
Potential harms
- A shopper may surrender unnecessary information or abandon a purchase after investing time in the basket.
- People cannot compare the offer without creating an identity record and may receive communications they did not seek.
Learn by comparison
What does this look like?
These fictional examples make the design mechanism easier to recognise. They do not depict a real company and do not establish that an individual interface is unlawful.
Illustrative example 1 · Online retail checkout
A fictional retailer removes guest checkout after an item is added and requires a full account, date of birth and saved password before payment can continue.
Potential consumer harm: A shopper may surrender unnecessary information or abandon a purchase after investing time in the basket.
Illustrative example 2 · Home-services quote
A fictional repair service asks visitors to create a profile and verify a phone number before it reveals even an indicative service price.
Potential consumer harm: People cannot compare the offer without creating an identity record and may receive communications they did not seek.
Account wall at guest checkout
A fictional retailer removes guest checkout after an item is added and requires a full account, date of birth and saved password before payment can continue.
Create an account to continue. No guest route is shown after the basket has been prepared.. Email address: Enter email address. Date of birth: Enter date of birth. Password: Enter password. Register and save my details
Choose how to check out. Guest checkout and optional account creation are presented together.. Delivery email: Enter delivery email. Continue as guest. Purpose and refusal effect, expanded: The form explains why “Continue as guest” is requested and what happens if it is not used.
Why the first version can mislead: The additional dependency controls access to the checkout goal. The panel states: “No guest route is shown after the basket has been prepared.” Reviewers need to establish whether “Register and save my details” is necessary for the selected task or pressures the user into a separable action. A shopper may surrender unnecessary information or abandon a purchase after investing time in the basket.
What a fairer design does: Keep a clearly labelled guest route beside account creation and request only delivery and payment data needed for the order.
Show annotated differences (2)
- Register and save my detailsIn “Account wall at guest checkout”, this element shows how forced registration can shape the decision.
- Purpose and refusal effect, expanded: The form explains why “Continue as guest” is requested and what happens if it is not used.In “Account wall at guest checkout”, this element keeps the clearer alternative visible at the same decision point.
Review questions (3)
- What functional need makes “Register and save my details” necessary for the online retail checkout goal, and can that need be met with less disclosure or commitment?
- Which fields or permissions are required, what happens on refusal, and does the resulting state support this criterion: “A desired goal is gated by account creation”?
- Could the stated purpose make this dependency genuinely necessary under the boundary “Account creation that is inherently necessary for persistent account functionality”, and what product evidence would demonstrate that necessity?
Profile required before price estimate
A fictional repair service asks visitors to create a profile and verify a phone number before it reveals even an indicative service price.
Unlock your estimate. Name, phone, birth date and password are required before any price appears.. Full name: Enter full name. Mobile number: Enter mobile number. Date of birth: Enter date of birth. Password: Enter password. Create profile
Estimated service price. The indicative range and assumptions appear before optional saving or booking.. Service postcode: Enter service postcode. View estimate without an account. Purpose and refusal effect, expanded: The form explains why “View estimate without an account” is requested and what happens if it is not used.
Why the first version can mislead: The additional dependency controls access to the pricing goal. The panel states: “Name, phone, birth date and password are required before any price appears.” Reviewers need to establish whether “Create profile” is necessary for the selected task or pressures the user into a separable action. People cannot compare the offer without creating an identity record and may receive communications they did not seek.
What a fairer design does: Show the estimate and its assumptions first, then offer account creation only when it is needed to book or save the quote.
Show annotated differences (2)
- Create profileIn “Profile required before price estimate”, this element shows how forced registration can shape the decision.
- Purpose and refusal effect, expanded: The form explains why “View estimate without an account” is requested and what happens if it is not used.In “Profile required before price estimate”, this element keeps the clearer alternative visible at the same decision point.
Review questions (3)
- What functional need makes “Create profile” necessary for the home-services quote goal, and can that need be met with less disclosure or commitment?
- Which fields or permissions are required, what happens on refusal, and does the resulting state support this criterion: “No equivalent guest or bypass route is available or discoverable”?
- Could the stated purpose make this dependency genuinely necessary under the boundary “legally or operationally necessary identity verification with clear explanation”, and what product evidence would demonstrate that necessity?
What is a fairer alternative?
Provide a clearly visible guest or no-account path unless registration is genuinely necessary, and explain necessity before collecting data.
Legal and information status
Legal position at a glance
The user must create an account, or is led to believe one is required, to complete a goal that could plausibly be provided without it. The gate converts an otherwise available task into account creation, so the user must create a persistent identity record before reaching the requested outcome. Risk increases where the mechanism changes a material consumer choice, hides a consequence or makes a genuine alternative harder to use. The taxonomy label remains a review prompt and does not establish an infringement.
Dark-pattern research taxonomy
Editorial analysis
The cited research sources support identification and comparison of this recurring interface mechanism. They do not determine that a particular interface is unlawful.
UCPD Articles 5 to 9, where applicable
Possible risk indicator
Depending on the trader, audience, overall presentation, material information and likely transactional effect, the facts may require a separate assessment under the applicable UCPD provisions.
Evidence layers and open questions
Applicable law, enforcement records, policy preparation, stakeholder input, editorial analysis and unknown future details remain visibly distinct.
Current lawCurrent law
The UX label “Forced registration” is not a standalone EU offence. Depending on the trader, audience, complete presentation, omitted information and likely transactional effect, the observed facts may require a separate assessment under the applicable UCPD provisions or another instrument within scope.
Under considerationUnder consideration
The Commission is preparing a Digital Fairness Act initiative, but the call for evidence does not select a final rule for forced registration or establish that this taxonomy term will appear in a proposal.
Editorial analysisEditorial analysis
The pattern definition, variants and examples on this page use the cited research taxonomy sources to support recognition and comparison. That analytical classification is not a legal conclusion about an individual interface.
UnknownUnknown
No published DFA proposal currently establishes a definition, covered actor, legal threshold, duty, remedy, transition rule or application date for forced registration. Those details remain unknown pending primary legislative text.
Context matters
Context and boundary cases
- A desired goal is gated by account creation.
- No equivalent guest or bypass route is available or discoverable.
- Registration is not evidently necessary for the specific function.
- Exclude or qualify the label where account creation that is inherently necessary for persistent account functionality.
- Exclude or qualify the label where legally or operationally necessary identity verification with clear explanation.
When a similar design can serve a legitimate purpose
- A similar design should not be classified this way where account creation that is inherently necessary for persistent account functionality.
- A similar design should not be classified this way where legally or operationally necessary identity verification with clear explanation.
Operational review
What teams should review
- Teams
- What functional need makes “Register and save my details” necessary for the online retail checkout goal, and can that need be met with less disclosure or commitment?
- Which fields or permissions are required, what happens on refusal, and does the resulting state support this criterion: “A desired goal is gated by account creation”?
- Could the stated purpose make this dependency genuinely necessary under the boundary “Account creation that is inherently necessary for persistent account functionality”, and what product evidence would demonstrate that necessity?
- What functional need makes “Create profile” necessary for the home-services quote goal, and can that need be met with less disclosure or commitment?
- Which fields or permissions are required, what happens on refusal, and does the resulting state support this criterion: “No equivalent guest or bypass route is available or discoverable”?
- Could the stated purpose make this dependency genuinely necessary under the boundary “legally or operationally necessary identity verification with clear explanation”, and what product evidence would demonstrate that necessity?
- Which complete journey evidence supports or contradicts the forced registration classification?
Evidence to retain
- Versioned captures of the Checkout and Pricing states before, during and after the relevant decision
- Configuration, content and event records supporting the observed forced registration mechanism
- Responsive, keyboard and assistive-technology review of every material option and consequence
- Control defaults, validation rules and consent or selection state changes
Legal map and implementation tools
Evidence base
Sources
- Dark commercial patternsOrganisation for Economic Co-operation and Development · Secondary · checked 2026-09-14 · OECD Digital Economy Papers No. 336
- Unfair Commercial Practices DirectiveEuropean Parliament and Council of the European Union · Primary · checked 2026-08-09 · Directive 2005/29/EC; CELEX 02005L0029-20220528
- Digital Fairness Act: call for evidence for an impact assessmentEuropean Commission · Primary · checked 2026-08-09 · Initiative 14622; Ares(2025)6275573
- Commission work programme 2026: Europe's Independence MomentEuropean Commission · Primary · checked 2026-09-14 · COM(2025) 870 final; CELEX 52025DC0870; Annex I item 30