WordPress Login Security: Stop Repeated Abuse and Protect Administrator Access Before It Becomes Account Takeover

Login Guard Focuses on Abuse Containment and Privileged Access

The current module protects authentication through lockouts, unknown-username controls, visible block state, wp-admin restrictions, administrator-change approval, geo policy, and honeypot signals. The older Shield-specific MFA and trusted-device workflow is not part of the supplied 7.4.5 package.

Three Dashboard Views Make Authentication Pressure Easier to Triage

The current Overview visualizes the security state stored by Login Guard instead of showing only configuration fields.

Contain Repeated Authentication Abuse Before WordPress Finishes the Normal Login Cycle

Baseline controls define maximum failed attempts, lockout duration, unknown-username handling, and a honeypot login field. The underlying login module checks active lock state before completing password authentication and uses stored attempt state to enforce the configured limits.

Unknown-user activity matters because repeated attempts against usernames or email addresses that do not exist are commonly associated with credential spraying, enumeration, or automation. Subscription controls allow separate known-user, unknown-user, and administrator thresholds, progressive lockout behavior, username-enumeration detection, and an option to permanently block a source when unknown-user failures cross the configured threshold.

Restrict Interactive Administration Without Breaking WordPress Background Traffic

Shield can restrict interactive wp-admin access by IP/CIDR and by approved roles or exact usernames. It validates IP entries and prevents enabling an empty allowlist or an obvious self-lockout. Trusted proxy headers are accepted only when the direct peer is in the configured proxy allowlist.

The boundary is intentionally narrow. REST, AJAX, admin-post, uploads, cron, registration, confirmation flows, and other non-interactive requests are handled separately so an administrative access rule does not become a broad application outage.

Require an Account Owner Decision Before New Privileged Access Becomes Normal

Login Guard can lock administrator access changes behind an Account Owner approval workflow. It covers new administrator accounts, administrator role promotions, protected custom roles, and direct grants of administrator-equivalent capabilities. The change is denied first, the owner is notified, and a pending approval appears for review.

The implementation uses signed owner, baseline, and approval state. It can protect WordPress capability and user_level records, revoke sessions when necessary, and use database triggers where the host permits them. If those triggers cannot be installed, application blocking and an integrity-rollback path remain part of the protection model. Prefix migrations coordinate with this database guard so maintenance does not bypass the administrator-protection workflow accidentally.

This is materially different from simply logging that a role changed. It creates a governance boundary around who is allowed to become administrator-equivalent.

Add Location Policy and Decoy Login Signals When They Fit the Environment

Subscription controls support Off, Alert Only, Block Only, or combined geo behavior using allowed country codes, plus a honeypot login URL designed to identify automated scanning. These controls can add context, but country rules should be applied carefully when administrators, customers, remote workers, or infrastructure operate from multiple regions.

Geo policy is not identity proof. VPNs, proxies, mobile networks, and cloud infrastructure can alter apparent location. Use it as another risk signal or restriction layer, not as a replacement for credential security and privileged-access governance.