Skip to main content

Account Security Options

Account Security Options​

Last verified: 2026-07-08

Use this guide when deciding which Account Security options to enable. The safest path is usually simple: protect important accounts with two-factor authentication, save recovery codes before enforcement, then add convenience options only when they match how the site is operated.

Detailed guides​

The sections below are short decision notes for the main Account Security options. Use the detailed guides when you need setup, troubleshooting, or support-facing boundaries.

Two-factor authentication​

Two-factor authentication adds a second login step after the password. Awthy's core method uses an authenticator app that generates a short code on the user's device.

Why you might want it​

Use this for administrators, shop managers, support staff, and customer accounts that need stronger protection than a password alone.

Advantages​

  • A stolen password is not enough to enter the account.
  • Authenticator apps work without SMS delivery.
  • It is a familiar setup for many store operators and staff.

Disadvantages​

  • Users can be locked out if they lose the device and did not save recovery codes.
  • Setup takes a few minutes and requires a compatible authenticator app.
  • Device clock problems can make codes fail until the clock is corrected.

Recommendation​

Set up two-factor authentication on at least one administrator account first. Save recovery codes before requiring it for anyone else.

If you start authenticator setup by mistake, choose Cancel setup. Awthy discards the pending enrollment and returns to the not-enrolled state without a page refresh. An already-active authenticator is not affected.

Recovery codes​

Recovery codes are one-time backup codes that let a user sign in if they lose access to their authenticator app.

Why you might want it​

Use recovery codes before enforcing two-factor authentication. They are the practical way back into an account when a phone is lost, reset, or replaced.

Advantages​

  • They provide a backup path that does not depend on the lost authenticator device.
  • Each code works once, limiting damage if one code is exposed.
  • They are simple enough for non-technical account owners to understand.

Disadvantages​

  • Anyone who can read an unused recovery code can use it to recover the account.
  • Codes must be stored somewhere private and durable.
  • Lost codes need to be regenerated while the user can still pass a second-factor check.

Recommendation​

Store recovery codes outside WordPress, such as in a password manager or another secure owner-controlled location. Do not send them through support forms, chat, email, or screenshots.

Passkeys​

Passkeys use a device-bound credential, usually protected by the device's unlock method, for phishing-resistant sign-in.

See Passkeys for setup, browser support, login challenge behavior, removal, and paid/customer boundaries.

Why you might want it​

Use passkeys for users who want faster sign-in and have devices or password managers that support WebAuthn/passkeys.

Advantages​

  • Passkeys resist common phishing attacks better than passwords and one-time codes.
  • They can be faster than typing a password and authenticator code.
  • They reduce reliance on users copying codes between apps.

Disadvantages​

  • They require browser and device support.
  • Users can be confused about where the passkey is stored.
  • Recovery still matters because a device or synced passkey account can be lost.

Recommendation​

Use passkeys as a strong convenience method after two-factor authentication and recovery are understood. Keep at least one recovery path available.

Trusted devices​

Trusted devices remember a browser so the user can skip repeated second-factor prompts for a limited time.

See Trusted Devices for trust creation, revocation, bypass limits, shared-device cautions, and admin/customer differences.

Why you might want it​

Use this when trusted staff or customers sign in often from the same private device and repeated prompts create friction.

Advantages​

  • Reduces repeated prompts for legitimate users.
  • Helps high-frequency administrators and shop managers work faster.
  • Can lower support requests from users who sign in often.

Disadvantages​

  • A remembered browser is less strict than requiring a second factor every time.
  • It is not appropriate on shared, public, or unmanaged devices.
  • Stolen or compromised devices should have trust revoked quickly.

Recommendation​

Allow trusted devices only when users understand they should use it on private devices they control. Review and revoke old devices periodically.

Connected login providers​

Connected login providers let users link an external identity provider, such as Google, GitHub, Facebook, or Microsoft Entra ID, to their WordPress account.

See External Identity Providers for provider setup, audience boundaries, callback testing, and troubleshooting.

Why you might want it​

Use this when customers or staff already rely on a trusted provider and you want a familiar sign-in path without giving up local WordPress account control.

Advantages​

  • Users can sign in with an identity they already use.
  • Some providers add their own risk checks and recovery process.
  • It can reduce password friction for customer accounts.

Disadvantages​

  • A provider outage or account problem can block that sign-in path.
  • Provider setup must be correct, especially redirect URIs and client secrets.
  • External login must not be treated as a replacement for account-security policy for privileged users.

Recommendation​

Enable only providers you operate and support. Test the provider configuration before presenting it to users.

Security activity​

Security activity shows recent account-security events without exposing sensitive audit details.

Why you might want it​

Use this to help account owners and support teams understand recent changes, such as passkey registration, trusted-device use, or recovery events.

Advantages​

  • Gives useful context without showing raw secrets.
  • Helps users spot unexpected account-security changes.
  • Helps support ask safer, more specific questions.

Disadvantages​

  • It is not a full forensic audit log.
  • It depends on audit storage and plan availability.
  • Users still need support guidance for anything suspicious.

Recommendation​

Use it as a display-safe account history. Escalate suspicious events through the site's support and security process.

Role enforcement​

Role enforcement requires selected WordPress roles to enroll in two-factor authentication.

Why you might want it​

Use this when administrators, shop managers, staff, or other privileged roles must meet a minimum login-security standard.

Advantages​

  • Makes protection consistent instead of relying on voluntary setup.
  • Reduces risk from privileged accounts with weak password habits.
  • Grace periods let users prepare before enforcement takes effect.

Disadvantages​

  • Bad rollout can lock legitimate users out.
  • Users need recovery codes and support guidance before enforcement.
  • Role slugs must be entered correctly.

Recommendation​

Start with administrators, test recovery, preview rollout impact, then expand to other roles only when support is ready.

External provider configuration​

External provider configuration stores the client ID, client secret, audience, redirect URI, and provider-specific settings needed for external login.

Why you might want it​

Use this when the site owner has an OAuth/OIDC app with a provider and wants users to link that provider to WordPress accounts.

Advantages​

  • Lets the site support provider-based sign-in with explicit configuration.
  • Separates staff and customer audiences.
  • Testing helps catch bad redirect URI or credential setup before users depend on it.

Disadvantages​

  • Misconfiguration can break login for that provider.
  • Client secrets must be protected.
  • Enabling the wrong audience can expose a login method to users who should not have it.

Recommendation​

Configure one provider at a time, test it, then enable the smallest audience that needs it.

Issuer​

The issuer is the name shown in authenticator apps beside the one-time code.

Why you might want it​

Use a clear issuer name so users can identify which code belongs to this WordPress site.

Advantages​

  • Reduces confusion when a user has many authenticator entries.
  • Helps support give clearer setup instructions.

Disadvantages​

  • Renaming later can confuse users if their authenticator app still shows the old label.

Recommendation​

Use the public site or store name users already recognize.

Drift window​

The drift window controls how many 30-second code steps are accepted before or after the current time.

Why you might want it​

Use a small drift window to tolerate minor clock differences between the server and a user's device.

Advantages​

  • Reduces false failures from small clock differences.
  • Helps legitimate users recover from minor time-sync issues.

Disadvantages​

  • Larger windows accept more possible codes.
  • Large values can hide server or device clock problems.

Recommendation​

Keep the default small window unless you have a real time-sync problem. Fix clocks rather than widening the window broadly.

XML-RPC and application passwords​

XML-RPC and application passwords are non-browser authentication paths used by some integrations, apps, and legacy workflows.

Why you might want it​

Use strict settings when you do not need these paths, or when enrolled users should not bypass browser-based second-factor checks through XML-RPC.

Advantages​

  • Reduces password-only bypass paths.
  • Helps protect enrolled users from legacy authentication exposure.
  • Makes integration access more intentional.

Disadvantages​

  • Blocking these paths can break legitimate integrations.
  • Some mobile apps, publishing tools, or automation may need application passwords.
  • Troubleshooting integration failures can require coordination with site operators.

Recommendation​

Block what you do not use. Before tightening production settings, identify integrations that depend on XML-RPC or application passwords.

Trusted proxies​

Trusted proxies are proxy IPs or CIDR ranges allowed to supply X-Forwarded-For for audit logging.

Why you might want it​

Use this when the site runs behind a known reverse proxy or edge network and audit logs should show the original client IP.

Advantages​

  • Improves audit event context behind trusted infrastructure.
  • Avoids trusting spoofed forwarding headers from arbitrary clients.

Disadvantages​

  • Wrong proxy entries can produce misleading audit source IPs.
  • Leaving out a real proxy can make logs show the proxy instead of the user.

Recommendation​

Enter only proxy IPs or CIDRs you operate or explicitly trust. Do not add broad ranges unless the infrastructure requires them.

System diagnostics​

System diagnostics show display-safe environment checks and a support report.

Why you might want it​

Use diagnostics before contacting support or when checking whether the environment can support account-security features.

Advantages​

  • Gives support useful context without exposing secrets.
  • Highlights environment problems that affect account security.
  • Makes troubleshooting more repeatable.

Disadvantages​

  • Diagnostics are a support aid, not a complete security audit.
  • A passing result does not prove every production workflow has been tested.

Recommendation​

Copy the support report when asking for help, but do not include passwords, recovery codes, authenticator secrets, private keys, or raw logs in support messages.

Last updated on