Account security
Review how sign-in safety, recovery, passkeys, trusted devices, suspicious activity, role changes, and support access should look before live accounts are connected.
Example account
No urgent action
Your sign-in and recovery status
This is a safe preview. No passwords, passkeys, recovery contacts, or live device records are collected.
Passkey readyPrimary sign-in method · example state
Review methods
Recovery confirmedContact hidden from this public demo
Review recovery
3 trusted sessionsLatest: desktop · Chicago area · 12 minutes ago
Review activity
Seller actions protectedExtra confirmation for payouts and high-value bids
Review access
Security preferences
Device cues, recovery notices, role boundaries, and private data controls
Verification status
Buyer trust, seller limits, pickup release, and payout-readiness gates
Security implementation reference
This optional reference explains the policies and connected services behind the customer-facing security dashboard. It is not another account setup path.
Sign-In Safety
- Account security should explain sign-in status, recent changes, recovery readiness, and high-risk action pauses in plain language.
- Bids, offers, seller payout setup, pickup release, private exports, and support access can require extra review.
- The demo does not ask visitors to enter passwords, codes, private identity documents, payment details, or real recovery contacts.
Recovery Paths
- Recovery should show verified email status, support fallback, locked-account guidance, and expected response windows.
- Lost access should preserve order timelines, support cases, seller obligations, and pickup windows while preventing risky changes.
- Support should see only the account details needed for the recovery request.
Passkeys and MFA
- Passkeys, backup methods, and multi-factor prompts should be shown as readiness states without collecting real credentials in the demo.
- High-value auctions, seller finance, identity checks, staff overrides, and exports can require a stronger confirmation step.
- Fallback methods should be clear enough that locked-out users know whether to use recovery, support, or a trusted device.
Device Sessions
- Device review should show device name, region-level location, recent activity, trusted state, and revoke action.
- New device notices should link to account activity, bids, purchases, seller tools, and privacy exports when relevant.
- Live device logs need retention rules and private-data boundaries.
Suspicious Activity
- Suspicious changes can include unusual bidding, repeated offer abuse, sudden seller changes, payout edits, report spikes, or unexpected exports.
- Each alert should show affected action, customer-safe reason, current status, next step, and support path.
- Risk signals should not expose private fraud rules to buyers or sellers.
Role Changes
- Buyer, seller, business seller, hub staff, support, trust, and operator permissions should stay separated.
- Role changes need approval, reason, scope, expiration, and audit history before they affect seller limits or staff-visible data.
- Users should understand which actions are available, paused, or pending review.
Privacy-Safe Controls
- Account security should link to privacy controls, data exports, deletion limits, support access logs, and notification preferences.
- Private details should remain separate from public profile, seller storefront, messages, and listing pages.
- Security notices should be required only when they protect account access, purchases, seller obligations, or legal records.
Owner Approval
- Owners should approve sign-in safety, recovery paths, passkeys and MFA, device sessions, suspicious activity, role changes, privacy controls, support access, and rollback rules.
- Launch review should connect account security to verification, mobile readiness, privacy, incident response, service activation, support operations, and access audit.
- Rollback should pause risky account actions without hiding existing order timelines, seller tasks, or support evidence.
Account Preferences
Notification choices, privacy boundaries, handoff settings, seller visibility, and security cues.
Verification Center
Buyer trust, seller status, hub release rules, finance readiness, and privacy boundaries.
Identity Checks
Buyer trust, seller limits, high-value auctions, pickup release, payout readiness, and appeals.
Account Roles
Role responsibilities, role-change audit, and staff boundaries.
Security Response
Suspicious activity, access issues, incident timeline, evidence, provider notices, and launch gates.
Privacy & Data
Data minimization, retention, staff access, processor review, incident response, and launch approval.
Access & Audit
Role permissions, staff actions, approval history, privacy boundaries, and support ownership.
Mobile App Readiness
Install behavior, alert routing, pickup reminders, account safety, and recovery readiness.
Support Operations
Recovery ownership, customer notices, evidence handoff, response targets, and escalation rules.
Current demo state
Account security is represented with guided settings.
The demo shows sign-in safety, recovery paths, passkeys and MFA, device sessions, suspicious activity, role changes, privacy-safe controls, and owner approval without collecting credentials or private recovery data.
Future platform state
Live account security needs identity services and support ownership.
Launch needs account creation, authentication, recovery workflows, device records, MFA or passkey enrollment, role permissions, security alerts, audit logs, provider monitoring, and staffed support escalation.