E-commerce
July 1, 2026
"I lost my phone, I can no longer log in." "My backup codes do not work." "How do I disable double-factor authentication?" Three tickets where mismanaged 2FA blocks account access and exposes a security risk if the agent bypasses procedures.
The e-commerce two-factor authentication support covers device loss, backup codes, lockouts, legitimate disabling, and identity escalation. Distinct from passwordless login (#837) and general login (#294): here, the customer has already enabled 2FA and can no longer validate the second factor.
This guide #839 deploys policy TWOFACT-SUP, flow TF-1 to TF-8, and matrix TWOFACT-MAP. Customer service pair of the future 2FA bot (#840).
Summary
Why does 2FA generate sensitive support tickets?
2FA protects the account and order history. Each second-factor failure blocks returns, addresses, and re-purchases. The agent disables 2FA without verifying identity or promises immediate recovery without an escalation procedure.
Five typical 2FA frictions
Lost or stolen phone: no more authenticator app or SMS
Backup codes exhausted: client did not save the codes
Missing SMS code: operator delay, wrong number
App reset: Google Authenticator without key export
Deactivation requested: client wants to remove 2FA without understanding the risk
The CNIL reminds that account securing must be accompanied by verifiable recovery procedures, without weakening protection through excessive convenience (CNIL, authentication 2026).
DTC Example
DTC Electronics, 14 twofact_ tickets/month. After TWOFACT-MAP: twofact_secure_resolution_rate 87%, identity bypass incidents 0 in 90 days.
TWOFACT #839 vs. MAGICLINK #837, LOGIN #294, ACCTEMAIL #825 and bot #840
Six pieces of content, six separate account security paths.
Quick Matrix
#839 TWOFACT: 2FA, backup codes, lost phone, identity escalation
MAGICLINK #837: passwordless distinct magic link second factor
LOGIN #294: global login password historical OTP
ACCTEMAIL #825: change login email distinct from 2FA recovery
ACCTDEL #823: account deletion must disable 2FA before delete
#839 = my 2FA is blocking me or I want to manage it. #837 = my magic link does not work.
Promise #839
Policy TWOFACT-SUP, tree TWOFACT-GATE, 8 macros, identity escalation matrix, KPI twofact_secure_resolution_rate.
Which twofact_* typologies should be classified?
Action-oriented classifier: backup code u2260 identity escalation u2260 SMS guide u2260 voluntary deactivation.
Eight TWOFACT-MAP typologies
twofact_lost_phone: lost device, no more authenticator
twofact_backup_invalid: backup codes rejected or lost
twofact_sms_not_received: SMS code missing
twofact_app_reset: auth app reinstalled without key
twofact_disable_request: wants to voluntarily remove 2FA
twofact_locked_out: too many attempts, account locked
twofact_method_confusion: SMS vs app vs email confusion
twofact_suspected_takeover: client suspects account compromised
TWOFACT-SUP Policy: agent and escalation rules
The TWOFACT-SUP policy defines what the agent can do without weakening account security.
Six TWOFACT-SUP rules
Verify identity before disabling: TWOFACT-ID-CHECK mandatory L2 escalation
Guide backup codes first: TWOFACT-BACKUP macro before bypass
Never disable L1 2FA: Admin 2FA reset L2 only after ID check
Document every action: 2FA method, action, agent, ticket date
Takeover alert: twofact_suspected_takeover → immediate TWOFACT-SECURE-ROUTE
Explain disabling risk: TWOFACT-RISK before voluntary disabling
Identity escalation matrix (agent)
L1: backup guide, SMS delay, method confusion
L2: 2FA reset after verifying recent order + ID document
L3 security: suspected takeover, fraud, account ownership dispute
Flow TF-1 to TF-8: standard resolution
Eight sequential steps, SLA P2 account security < 4 h, immediate L3 if takeover.
Flow TF-1 to TF-8
TF-1 Triage: read request, tag twofact_*, urgency takeover
TF-2 Lookup: active 2FA method Shopify or third-party, last login
TF-3 Educate: TWOFACT-METHOD-DIFF if method_confusion
TF-4 Classify: twofact_* via TWOFACT-MAP
TF-5 Execute: backup guide, SMS wait, L2 reset escalation, secure route
TF-6 Confirm: macro TWOFACT-DONE exact scope
TF-7 Test: ask to confirm login or 2FA reactivated
TF-8 Close: KPI twofact_secure_resolution_rate
Eight ready-to-paste TWOFACT-* macros
Clear macros on backup, escalation, and security risk.
TWOFACT-* Library
TWOFACT-METHOD-DIFF: “SMS: code received via text message. App: code generated by Google Authenticator or similar. Email: link or code depending on config.”
TWOFACT-BACKUP: “Use a one-time backup code from your saved list. Each code works only once.”
TWOFACT-SMS-WAIT: “SMS code within 2 mins. Verify number {{phone_masked}} on your account. Try again after 60 seconds.”
TWOFACT-RISK: “Disabling 2FA reduces the protection of your account and order history. We recommend keeping it enabled.”
TWOFACT-ID-CHECK: “To reset 2FA, we verify your identity: last order + ID document. Processing time {{sla}}.”
TWOFACT-SECURE-ROUTE: “Account potentially compromised: 2FA maintained, password reset, security team will contact within 2 hours.”
TWOFACT-REENABLE: “After recovery, re-enable 2FA and save new backup codes.”
TWOFACT-DONE: “Recap: action {{action}}. Next step {{next_step}}. Contact us if block persists.”
TWOFACT-GATE tree and Shopify configuration
Decision tree before unverified 2FA deactivation.
TWOFACT-GATE
Backup codes available? → TWOFACT-BACKUP before escalation
SMS missing? → SMS-WAIT then look up profile number
Lost phone without backup? → ID-CHECK L2 escalation
Suspected takeover? → SECURE-ROUTE L3, do not disable N1
2FA Ops Checklist
Document L2 2FA reset procedure in Shopify admin. Train agents: never disable without ID check. Tag twofact_* for escalation audit. Sync ACCTDEL #823 procedure if active 2FA account deletion.
KPI, QA and handoff to bot #840
Measuring TWOFACT detects security bypasses and missed escalations.
Four TWOFACT KPIs
twofact_secure_resolution_rate: resolved compliant procedure / total
twofact_id_check_compliance: % of 2FA resets with documented ID check
twofact_bypass_incidents: disable without verification, target 0
twofact_repeat_7d: reopening of same topic within 7 days
Handoff bot #840
Export TWOFACT-MAP to intents bot_twofact_backup, bot_twofact_guide. Guardrail TWOFACT-NO-DISABLE-BOT: never promise 2FA disabling without L2 escalation.
Edge cases: B2B, admin staff, shared account
Three cases outside the standard flow.
B2B Pro Account
Multiple contacts, 2FA on company admin email. Verify mandate before L2 reset.
Shopify Admin Staff vs Customer
Back-office staff 2FA is separate from the customer account 2FA. Do not mix procedures.
Phone Number Change
SMS 2FA sent to the old number. Handoff ACCTEMAIL #825 if a profile update is required.
Agent training: 25 minutes TWOFACT
Module: backup first, ID check before disable, SECURE-ROUTE if takeover.
Exercises
Ticket A: lost phone → BACKUP then ID-CHECK L2
Ticket B: wants to disable 2FA → RISK then ID-CHECK if confirmed
Ticket C: “someone changed my email” → SECURE-ROUTE L3
How Qstomy structures TWOFACT in your stack
Qstomy routes twofact_*, blocks macros disable 2FA N1 and escalates takeover automatically.
Three building blocks
Routing: intent two_factor vs login_general vs account_takeover
Guardrails: NO-DISABLE-N1 before close
Bot #840: guides backup tier 1 without bypassing security
FAQ and deployment checklist for TWOFACT
FAQ
Can L1 Agent disable 2FA?
No. ID-CHECK L2 minimum. twofact_bypass_incidents target 0.
Difference from #837 passwordless?
#837 = magic link without password. #839 = second factor already enabled blocks login.
Customer without backup codes?
Escalate to L2 TWOFACT-ID-CHECK. No admin shortcuts without verification.
7-day Checklist
Day 1: TWOFACT-SUP + TWOFACT-MAP + L1 L2 L3 escalation matrix
Day 2: 8 helpdesk macros
Day 3: L2 Shopify 2FA reset process documented
Day 4: 25-minute agent training
Day 5: twofact_* tags + KPIs
Day 6: SECURE-ROUTE takeover drill
Day 7: #840 NO-DISABLE-BOT brief
Linking
Enzo
July 1, 2026
