Technical summary
What is the current Aegisify Shield Security 7.4.5 support status for the legacy topic “Alert Integrations (Login Guard, File Integrity, Malware, MFA)”? is retained as a compatibility/status FAQ because the supplied Shield 7.4.5 source package does not contain a current MFA/TOTP/trusted-device/backup-code implementation. This article is grounded in the supplied Aegisify Shield Security 7.4.5 plugin package. It documents current behavior and defaults rather than relying on older FAQ wording.
Current-version support status
Do not use older MFA setup instructions for Shield 7.4.5. The supplied 7.4.5 source package contains no current MFA/TOTP enrollment engine, QR-code enrollment workflow, trusted-device subsystem, or backup-code setting surface. This FAQ is retained so support systems can answer the legacy topic accurately. Shield 7.4.5 does provide login abuse controls, password-reset rate limits, administrator-access controls, registration protections, unknown-username handling, and permanent-block behavior. If MFA is required, use a separately verified MFA implementation rather than assuming this Shield package provides one.
Where administrators configure or verify it
Primary wp-admin path: wp-admin → Aegisify Shield → Login Guard. Exact controls can be distributed across the related tab/page when the feature is composed of multiple engines.
Current 7.4.5 defaults and related controls
The table below lists settings in the supplied current source that are directly related to this topic. The current default/bound/status shown is code-derived. Where the product does not define a named Medium preset, the shipped default is documented as the baseline operating point rather than inventing a value.
| Setting | Current default / bound / status | Why this default | How to tune safely |
|---|---|---|---|
login_guard.max_attempts |
5 | The shipped value of 5 is the current baseline threshold or capacity. It is intentionally finite so the control can provide useful protection or bounded resource use without starting at an extreme. | For abuse/rate thresholds, a lower number is generally more aggressive and can stop attacks sooner but may affect legitimate bursts; a higher number is more tolerant but allows more activity before intervention. Change incrementally and validate against logs. |
login_guard.lockout_minutes |
15 | The shipped value of 15 is the current timing baseline used to balance responsiveness, user impact, and processing overhead. | For the same event limit, a longer accumulation window or lockout/cooldown usually increases protection and user disruption; a shorter interval resets sooner. Tune together with the corresponding event threshold. |
login_guard.login_abuse_action |
block | Block is the shipped enforcement choice for this specific control, indicating that the current product considers a positive match sufficiently high confidence to stop by default. | Where this control exposes Off / Monitor / Block: Off disables its decision path; Monitor records/evaluates without blocking; Block enforces the decision. Start with Monitor for uncertain traffic, then move to Block after reviewing false positives and exceptions. |
login_guard.password_reset_rate_limit_enabled |
1 | Enabled in the shipped baseline because the control provides broadly useful visibility, validation, compatibility, or protection without requiring a site-specific value. | ON activates the behavior; OFF removes that specific behavior. Use OFF only when the control is intentionally unnecessary, another trusted layer owns the function, or a compatibility investigation proves the control is involved. Re-enable after testing when protection is still required. |
login_guard.password_reset_action |
block | Block is the shipped enforcement choice for this specific control, indicating that the current product considers a positive match sufficiently high confidence to stop by default. | Where this control exposes Off / Monitor / Block: Off disables its decision path; Monitor records/evaluates without blocking; Block enforces the decision. Start with Monitor for uncertain traffic, then move to Block after reviewing false positives and exceptions. |
login_guard.pro_unknown_user_permanent_block_enabled |
on | Enabled in the shipped baseline because the control provides broadly useful visibility, validation, compatibility, or protection without requiring a site-specific value. | ON activates the behavior; OFF removes that specific behavior. Use OFF only when the control is intentionally unnecessary, another trusted layer owns the function, or a compatibility investigation proves the control is involved. Re-enable after testing when protection is still required. |
login_guard.administrator_lock_enabled |
1 | Enabled in the shipped baseline because the control provides broadly useful visibility, validation, compatibility, or protection without requiring a site-specific value. | ON activates the behavior; OFF removes that specific behavior. Use OFF only when the control is intentionally unnecessary, another trusted layer owns the function, or a compatibility investigation proves the control is involved. Re-enable after testing when protection is still required. |
login_guard.administrator_db_guard_enabled |
1 | Enabled in the shipped baseline because the control provides broadly useful visibility, validation, compatibility, or protection without requiring a site-specific value. | ON activates the behavior; OFF removes that specific behavior. Use OFF only when the control is intentionally unnecessary, another trusted layer owns the function, or a compatibility investigation proves the control is involved. Re-enable after testing when protection is still required. |
Adjustment strategy
Change one control at a time, save it through the product UI, reproduce the legitimate and malicious/test flow, and review the product log/status surface. For enforcement controls, use Monitor/Observe first when normal behavior is uncertain; move to Block only after the signal is reliable. For thresholds, do not jump directly from the default to an extreme unless an active incident requires emergency containment and a recovery path exists.
Operational guidance
For WooCommerce, membership, social-login, REST, AJAX, or custom-registration sites, test legitimate account creation and recovery flows before increasing enforcement. Protect the abuse path without blocking normal WordPress/plugin account workflows, and keep an administrator recovery path.
Technical keywords
Aegisify Shield Security, 7.4.5, alert, authentication, brute, checksum, credential, email, file, guard, hash, integrations, integrity, lockout, login, malware
Source baseline
Verified package: Aegisify Shield Security 7.4.5. Primary source files: includes/configuration/class-as-configuration-schema.php; includes/modules/class-as-module-login-guard.php; includes/modules/login_guard/class-as-login-guard-user-protection.php; includes/admin_pages/hardening/class-as-page-hardening-tab-endpoint-protection.php; includes/modules/class-as-module-hardening.php; includes/admin_pages/class-as-page-db-tools.php. If a future plugin version changes these settings, support should re-read the installed version rather than carry these defaults forward automatically.