Cyber Essentials for Okta: configuration guide

For Cyber Essentials v3.3, configure Okta so every user of an in-scope cloud service authenticates with MFA, privileged work uses separate administrative accounts, and authentication policies do not create undocumented bypasses. A 12-character password or 12-hour session is not an unconditional Cyber Essentials rule; use the NCSC password-quality options and document the controls your implementation actually applies.

• MFA for every user of in-scope cloud services, and wherever available
• Password quality using one of the v3.3 options, including MFA, 12+ characters, or 8+ characters with a common-password deny list
• No password-only bypass of required MFA; check actual basic/OAuth authentication routes rather than treating IMAP/POP protocol names alone as evidence
• Separate administrative accounts for privileged work
• Session management appropriate to your risk and the service, without presenting a non-scheme timeout as mandatory

Okta's engineering maps to this with Authenticators, Authentication Policies, and Global Session Policies.

The following is a suggested stronger local baseline, not an unconditional scheme factor/complexity mandate. Check your Okta edition and engine, supported authenticator assurance and actual enrolment/enforcement.

In Security > Authenticators:

• Okta Verify (push / biometric): primary recommended factor
• FIDO2 / WebAuthn: recommended stronger option for administrators; not the only scheme-recognised MFA route
• Security Questions: disable
• SMS / Voice: consider suitable stronger alternatives. SMS is recognised by Cyber Essentials; a local restriction must not be presented as a scheme ban or universal NIST deprecation
• Password: apply the applicable credential-strength route with breached-password blocking; avoid enforced complexity or periodic expiry and change compromised credentials promptly

Okta Identity Engine app sign-in policies and Classic Engine terminology/capabilities differ. Check your actual engine and policy assignments.

Verify effective required MFA for each cloud application and wherever available elsewhere. The following prompt/assurance settings are local hardening examples; a valid existing MFA session can satisfy authentication without a fresh prompt on every login:

• Require MFA every time on admin apps (Okta Admin Console, AWS, GCP, Azure portals)
• Require MFA every session on most end-user apps
• Require phishing-resistant factor (FIDO2 / Okta Verify with FastPass) for administrators
• Block unknown devices option for critical apps (Admin Console, financial systems)

Export the Authentication Policy JSON for each app and keep it - it's one of the cleanest evidence artefacts.

Review the supported Global Session Policy interface for your engine. These illustrative local timers are not scheme maximums:

• Maximum Okta session lifetime: 12 hours
• Maximum Okta session idle time: 2 hours
• Require re-authentication on every session (or bounded by the 12-hour maximum)
• Persistent cookies off for untrusted browsers

• Minimise standing Super Admin access to what is needed. Two-to-three is a local target, not a scheme maximum; use supported delegated roles for suitable tasks.
• Named admin accounts - no shared admin logins
• Separate admin identity for each admin (their everyday user account is not a Super Admin)
• Break-glass account(s) - one or two accounts with Super Admin, FIDO2 hardware keys, excluded from some Authentication Policies to remain accessible if something breaks, independent strong authentication, controlled use and safe recovery testing; policy exclusions must not create password-only cloud access
• IP-restrict admin sessions to office IPs and VPN ranges if feasible

Not strictly required by Cyber Essentials but highly recommended:

• ThreatInsight enabled - blocks known-bad IPs from sign-in attempts
• Okta Device Access or Okta FastPass - ties sessions to device posture, strengthens user-access-control evidence
• Device integration via endpoint management (Jamf, Intune, Kandji) for device assurance

Remove or disable accounts and privileges when no longer needed. The following are illustrative operational practices, not prescribed same-day or thirty-day scheme deadlines:

• Inbound SCIM provisioning from your HR system where possible
• Scheduled (e.g. daily) reconciliation between HR active employees and Okta active users
• Leaver workflow: suspend immediately, delete within 30 days

• Okta administrator/Super Admin list with justification for necessary privileges
• Authentication Policy JSON export for each critical app
• Global Session Policy screenshot
• Authenticator enrolment plus effective enforcement and representative sign-in evidence; no universal phishing-resistant-factor percentage threshold
• User leaver report matched against HR leaver list for last 12 months

1. Password-only bypass or unjustified session exposure. Verify effective MFA and suitable session controls; seven days is not by itself a scheme failure timer.

2. Password factor without a MFA requirement in one legacy Authentication Policy. Audit every policy.

3. A shared admin account from the original rollout ("sso-admin"). Replace with named admins.

4. Weak or ineffective authentication flows. Recommend suitable stronger methods; SMS is not automatically a scheme failure, and ordinary push is not universally phishing resistant.

5. Unsafe recovery design. Plan supported emergency access and test safely. Two break-glass accounts/key storage are local implementation choices, not universal scheme prerequisites.

The readiness check supports preparation. Share scoped authentication and account evidence when requested. Exact read-only API integration and first-time percentages need verified service/cohort records; no scan or factor-enrolment percentage guarantees certification.

Start Cyber Essentials - from £299.99 + VAT | Pricing tiers | CE Plus