The Dashboard is your at-a-glance security posture view. It summarizes configuration risks, module health, and recent activity so you can quickly see what needs attention.

• Overall Security Score: a high-level indicator (for example, 77/100) that reflects posture checks such as pending updates, admin count, and database conditions.
• Core Health Metrics: WordPress version, PHP version, plugin/theme update counts, administrator accounts, database size, and DB prefix status.
• Pro Intelligence (if licensed): aggregated summaries across modules and premium indicators.
• Security events (last 24 hours): quick counts for logins, failures, lockouts, and admin account changes.
• Modules overview: jump buttons to each module (Activity Log, Login Guard, File Integrity, Hardening, Security Headers, Malware Tools, DB Tools).

The Activity Log records important events so you can audit changes and investigate suspicious behavior.

Typical events captured

• Successful and failed logins
• Login lockouts and rate-limit actions
• Administrator account and role changes
• Module configuration changes (hardening, headers, monitoring settings)
• Security scanning actions (integrity and malware scans)
• Database tool actions (exports, optimizations, prefix operations) when enabled

How to investigate an incident

1. Start with a time window: identify when the suspicious behavior happened.
2. Filter by category (for example: logins, admin changes, file monitoring, malware).
3. Open the event details and record key fields (user, IP if present, action, module).
4. Export to CSV/JSON if you need to share the evidence or store it with an incident ticket.

Filtering, pagination, and retention

• Use advanced filtering to narrow to a specific user, event type, or severity.
• Adjust pagination (25 / 50 / 100) when reviewing high-volume sites.
• Set retention to balance audit needs vs. database size.

Login Guard protects your login form against brute-force and credential stuffing by monitoring failures, applying lockouts, and supporting MFA policies.

Recommended setup (safe defaults)

1. Enable lockouts for repeated failed logins.
2. Enable rate limiting to slow down repeated attempts.
3. Turn on email alerts for lockouts (so you know when the site is being attacked).
4. If available, configure trusted devices to reduce MFA prompts while keeping protection strong.

MFA foundations

AegisShield includes a modern MFA foundation with TOTP enrollment and recovery flows. When you enable MFA:

• Enroll one administrator first, verify that login works, and confirm recovery options.
• Document a recovery plan (hosting panel/SFTP access) before enforcing MFA for all admins.
• Apply a policy gradually: Admins → Editors → other roles, depending on your risk tolerance.

Custom rules

Use custom lockout rules and geo rules carefully. Always test with a non-primary admin account first to avoid self-lockout.

File Integrity monitoring detects unexpected changes to WordPress core files, plugins, and themes. It helps you spot tampering, malicious edits, or unauthorized uploads.

Baseline, then monitor

1. Confirm the site is in a known‑good state (after updates, before experiments).
2. Create a baseline scan.
3. Enable monitoring and review new findings regularly.

Reviewing findings

• New: files that did not exist at baseline.
• Modified: files whose content changed compared to baseline.
• Deleted: files that existed at baseline but no longer exist.

Exclusions and alerting

• Exclude folders that change legitimately (cache directories, temporary folders).
• Enable email alerts for high-risk changes (core files, admin‑area plugins, authentication-related files).
• Use scan history to compare before/after changes. Delete old history entries only after you no longer need them for auditing.

Hardening applies curated WordPress hardening toggles to reduce attack surface. Each control is designed to be understandable and reversible.

Examples of what hardening controls typically cover

• Reduce exposure of sensitive endpoints (where safe and compatible).
• Disable risky behaviors (where safe), such as unnecessary file edits via the dashboard.
• Strengthen defaults for common misconfigurations.

How to apply hardening safely

1. Change one setting at a time.
2. Test core flows: login, forms, checkout (if ecommerce), and critical pages.
3. If something breaks, revert the last setting and retest.
4. Document your chosen baseline hardening configuration.

Security Headers helps you apply modern browser protections that reduce common web attack classes (clickjacking, MIME sniffing, unsafe referrers, and more).

Safe starting set

• X-Frame-Options: reduces clickjacking risk.
• X-Content-Type-Options: reduces MIME sniffing issues.
• Referrer-Policy: limits referrer leakage.

HSTS (HTTP Strict Transport Security)

HSTS can improve HTTPS enforcement but can cause long-lived browser behavior. Enable only when:

• Your site always uses HTTPS
• You control all served subdomains if you enable subdomain rules
• You understand rollback impact (browsers remember HSTS for the configured duration)

Content Security Policy (CSP) builder & profiles (Pro)

CSP can dramatically reduce XSS risk but must be configured carefully. AegisShield includes CSP builder settings and security header profiles to help you apply policies safely.

1. Start with a conservative preset.
2. Test your site’s frontend and admin interfaces.
3. Gradually tighten allowed sources as you identify required scripts and styles.
4. Keep a rollback plan (disable CSP profile) if critical functionality breaks.

Malware scanning detects suspicious patterns in PHP code and common indicators of compromise. It is designed for clarity: you review findings, understand the risk level, and decide the appropriate action.

Scan types

• Quick Scan: faster scan intended for frequent use.
• Deep Scan: more thorough scan intended for periodic review or after suspicious activity.
• Attack Story (Pro): correlates malware hits, file changes, and admin activity into a single timeline view.

Review workflow

1. Run a scan.
2. Sort findings by severity (High / Medium / Low).
3. Open a finding and review why it was flagged (obfuscation, suspicious functions, unexpected payloads).
4. Decide an action: ignore (if false positive), investigate, quarantine (if enabled), or restore from backup.
5. After remediation, rerun a scan to confirm the site is clean.

Scheduling and metadata

Some builds include scan metadata (type, file count, suspect count) and scheduled scans. If your UI indicates “scheduler will be available in a future release,” use manual scans and operational checklists until scheduling is available.

Database Tools provides database visibility and safety features such as table growth monitoring, exports, and a guided DB prefix manager.

Health and growth monitoring

• Track database size and table growth. Sudden growth can indicate logging noise, spam, or malicious data injection.
• Use exports to review table summaries offline.

Prefix manager (advanced)

The DB prefix manager helps you change the WordPress table prefix in a guided way. This is an advanced operation: test on staging first.

1. Review the preview/dry-run, if available, to understand what will change.
2. Create a database backup snapshot before a prefix change.
3. Run the prefix change and allow internal key updates (prefix-bound keys) to complete.
4. Verify the site loads, logins work, and admin pages operate normally.
5. If issues occur, use rollback/restore tools if available and restore from backup if needed.

This page centralizes licensing and global operational settings.

• License status: Active (Pro enabled), Inactive, or Expired.
• SMTP settings: configure outbound email delivery for alerts; send a test email to validate.
• Registration: connect the plugin to your Aegisify account (if applicable).

Before relying on alerts, always verify that your hosting environment can deliver email, and confirm the test email arrives in the inbox you expect.

1. Try logging in from a different trusted device/network if you use geo rules.
2. If you have hosting panel access, temporarily disable AegisShield by renaming the plugin folder via SFTP/SSH, then log in and revert the risky setting.
3. If the issue is MFA enforcement, disable MFA policy temporarily, confirm access, then re-enable with a staged rollout.

Always keep at least two administrator accounts and test policy changes with the non-primary admin first.

1. Disable CSP profile/preset first (if enabled), then reload key pages.
2. If you enabled HSTS, confirm your site and required subdomains all serve HTTPS correctly.
3. Re-enable headers one-by-one to isolate the header causing breakage.

This is expected after legitimate updates.

1. Confirm the changes correspond to known updates (WordPress core, theme, plugin updates).
2. If the site is known‑good, create a new baseline.
3. If changes are unexpected, investigate the specific files and correlate with Activity Log events.

1. Start with High severity findings.
2. Check whether the flagged file is a core/plugin/theme file or an unexpected file.
3. Compare with File Integrity (was the file modified recently?).
4. If you are unsure, restore the file from a known‑good backup instead of editing in place.
5. Rerun the scan to confirm remediation.

Using a custom table prefix can reduce the value of automated attacks that assume default table names, but it is not a complete defense. Treat prefix changes as an advanced operation.

1. Create a database backup snapshot first.
2. Use the Prefix Manager preview/dry-run if available.
3. Change prefix during a maintenance window, then test the site thoroughly.