Loading

Fixing Common Check-up Findings

Most installations show the same handful of findings the first time the Security Check-up is run. This article takes the common ones in turn: what the finding means, where it is fixed, and what to check afterwards.

Where to find it

Architect Panel → Security:

  • Security Check-up — the findings and their assessments
  • Disabled User Accounts — identities that may not sign in
  • Blocked IP Addresses — addresses blocked now
  • Blocked User Accounts — accounts blocked now

Architect Panel → Configuration:

  • Site Settings — 2FA, password policy, blocking thresholds and session settings

Admin Panel → User Administration:

  • All Users — the accounts the dormant and administrator lists point at

Multi-factor authentication

  • Enforcement: "Optional - not enforced for anybody" (Action needed). 2FA is available but nobody is required to use it. Turn on enforcement in Site Settings, after checking enrolment: see 2-Factor Authentication.
  • Enforcement: "Enforced for specific groups only" (Review). Accounts outside the listed groups can sign in with a password alone. Check that every group with administrative access is on the list.
  • E-mail codes: "Offered as the ONLY method" (Action needed). A code sent to the account's own mailbox is close to a single factor. Ask your hosting administrator to offer an authenticator app as well, and treat e-mail as the fallback.
  • Accounts with an authenticator app, shown as "X of Y". Only authenticator apps count here: an account that uses SMS or e-mail codes alone is counted as without one. Use View accounts to list the rest and chase the people concerned before you enforce.

Password policy

  • Minimum length below 12 (Review below 12, Action needed below 8). The note explains that 8 is accepted alongside multi-factor authentication or common-password blocking, and 12 without. Raise it in the Password Policy group of Site Settings: see Password Policy.
  • Block common passwords switched off. Switch it back on; it ships on.

Brute-force protection

  • Blocking by IP address: Disabled or Blocking by account: Disabled (Action needed). Failed sign-ins are not being counted, so password guessing is unthrottled. Turn both on in Site Settings. Blocking by account matters even when blocking by address is on, because it stops guesses spread across many addresses.
  • More than 10 attempts allowed (Review). Cyber Essentials expects lock-out or throttling after no more than 10 failed attempts. Lower the threshold.
  • CAPTCHA on the sign-in form (Not implemented). There is no setting for this. The blocking settings above are what protect the sign-in form.

Sessions

  • Idle timeout longer than a day (Review). Shorten Maximum Session Idle Time in Site Settings, and consider the timeout warning so people are not caught out: see Session Management.
  • "Enabled, but INERT" against tying a session to its IP address or browser (Review). The setting is on but does nothing, because database session verification is off. Either switch verification on or switch the inert setting off so the configuration says what it does.
  • Cookie flags marked Set in config/config.php. These are changed by your hosting administrator, not on any screen.
  • Absolute session lifetime and Concurrent session limit (Not implemented). Record them as absent; there is nothing to configure.

Accounts and access control

  • Enabled accounts with no successful sign-in in 90 days (Review when above zero). Use View accounts to list them. The list includes accounts created recently and never used, so check the creation date before acting. Disable accounts nobody needs rather than deleting them, so the audit trail still resolves.
  • Accounts with administrative access. A count, not a finding, but the list behind it is the one an assessor will ask for. Confirm each person still needs it, and that administrators use a separate account for everyday work where your policy requires it.
  • Accounts explicitly disabled. Identities refused at sign-in whatever their password, listed on Disabled User Accounts.

Checking your fix

  1. Change the setting on the screen the finding's button opens and save it.
  2. Reopen Security Check-up from the panel.
  3. Confirm the assessment has changed and read the new note, which sometimes points at a related setting.
  4. Check the Security Configuration card on the Status Panel: its count of settings to review should have fallen by the same amount.

Worked example

A housing association's first check-up shows nine findings needing a decision. The administrator turns on blocking by account at 10 attempts in 15 minutes, raises the minimum password length to 12, and shortens the idle timeout from fourteen days to four hours with the warning switched on. The 2FA finding is left at Review while enrolment rises, with enforcement planned for the following month. The dormant list of 31 accounts goes to team managers, and 27 are disabled within a week. The rerun shows two findings left, both with a recorded reason.

Recommendations

  • Fix the Action needed findings first; they are the ones an assessor records against you.
  • Do not switch a setting on just to turn it green; read the note to see what it costs your users.
  • Record a reason for every Review you keep, so the next check-up does not reopen the same debate.
  • Pass the config/config.php findings to your hosting administrator as a single list.