TL;DR: Cyber Essentials 2026 will widen compliance scope to any cloud service accessed with a business email or account, and require MFA to be enforced wherever it is available, according to Push Security. The shift exposes shadow apps, ghost logins, and incomplete app visibility as governance failures, not just audit issues.
At a glance
What this is: Push Security analyses how Cyber Essentials 2026 expands SaaS scope and tightens MFA expectations around business accounts, shadow apps, and ghost logins.
Why it matters: IAM and NHI teams need to understand that audit scope is shifting from managed SSO estates to the full SaaS login surface, including accounts and authentication paths outside central control.
Context
Cyber Essentials 2026 changes the governance baseline for SaaS access by redefining what is in scope and how compliance is measured. In practice, the scheme now treats cloud access through a business email or account as part of the compliance surface, even when the app sits outside the corporate SSO estate.
The governance gap is visibility, not policy wording. If teams cannot see every login method, every concurrent credential, and every shadow app, they cannot prove that MFA is enforced where it is available or identify the accounts that fail the new attestation test.
Key questions
Q: What breaks when SaaS apps are used outside SSO and central IAM?
A: The main failure is lifecycle control. If an app is not tied to SSO or the identity provider, offboarding, recertification, and access logging may never reach it. That leaves active accounts, orphaned licenses, and audit gaps even when the business believes access was removed.
Q: Why do apps with optional or add-on MFA create audit risk?
A: Optional MFA creates risk because the organisation cannot assume protection at the account level unless it is enforced on every in-scope login. If MFA is only available in a paid tier or left to user self-enrolment, auditors may find that some accounts are still accessible through weaker methods.
Q: How should security teams handle MFA gaps across SaaS applications?
A: Security teams should treat SaaS MFA as a coverage problem, not a single control deployment. The priority is to identify every login path, including browser-based access, exceptions, and legacy applications, then close the gaps with enforced policy and evidence. If you cannot show where MFA is missing, you cannot prove the control is reliable.
A: They should treat them as part of the same identity surface, because externally managed users often use separate browsers, local credentials, or unmanaged sign-in methods. If those accounts are excluded from reviews, the organisation can pass policy checks on paper while missing real access risk.
Technical breakdown
Why SSO visibility no longer covers the full SaaS estate
Traditional identity programmes assume that once an application is federated through SSO, downstream access is effectively governed. That assumption breaks when users self-adopt SaaS tools, create local accounts, or sign in with a personal or alternate credential. The result is parallel authentication paths inside the same app, with central IdP dashboards showing only part of the story. For Cyber Essentials 2026, that architectural blind spot matters because compliance now depends on the actual login path, not just the preferred one.
Practical implication: inventory applications by observed login method, not by onboarding register alone.
Ghost logins and why MFA enforcement becomes inconsistent
A ghost login is a local or alternate credential that remains active alongside a federated login, often with different MFA strength or none at all. SaaS vendors frequently expose MFA in uneven ways, such as tenant-level settings, paid tiers, or user self-enrolment that admins cannot centrally verify. That makes MFA enforcement a distributed control problem. Even where SSO is protected, a parallel local password can remain the easier path for both users and attackers, which is why audit scope now expands to individual account states.
Practical implication: verify MFA status at the app account level and remove fallback credentials where enforcement is not uniform.
Why auditors care about the actual authentication path
Cyber Essentials attestation is moving toward evidence that reflects real behaviour, not just policy intent. If an auditor can ask a user to demonstrate access to a cloud service and see a password-based or MFA-absent path, the existence of a secure IdP does not rescue the control failure. The control problem is therefore not whether an organisation has SSO, but whether every in-scope service is actually reached through an approved and protected authentication method. That is a lifecycle and governance issue as much as an authentication one.
Practical implication: test user journeys for in-scope apps the way an assessor would, including shadow and contractor accounts.
Threat narrative
Attacker objective: The attacker wants to use valid credentials and weak or absent MFA to access SaaS accounts that governance teams have not fully mapped or protected.
- Entry occurs through a SaaS account that is accessible with a business email or account, even when the application is outside the central SSO estate.
- Credential access succeeds because a local password, reused password, or MFA-absent login path remains available alongside the federated route.
- Escalation follows when attackers use valid credentials and bypass the stronger authentication path that teams believed covered the application.
- Impact is account takeover across shadow or unmanaged apps, which can expose data, tokens, or downstream business systems tied to the account.
Breaches seen in the wild
- Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
- SonicWall SSL VPN account compromises 2025: Attackers used valid credentials to log in to more than 100 SonicWall SSL VPN accounts across 16 environments in October 2025.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Cyber Essentials 2026 turns SaaS login paths into a governance problem, not an attestation afterthought. The scheme now reaches beyond the IdP boundary and into every cloud service accessed with a business account, which means visibility of the real authentication path becomes the control surface. Organisations that still equate SSO coverage with complete access governance will miss the accounts most likely to fail assessment.
Shadow app visibility is now a compliance prerequisite. When a user can self-adopt a SaaS tool, create a local password, or authenticate through an unmanaged route, the organisation no longer controls the evidence needed for attestation. The practical implication is that app discovery, login-path discovery, and account lifecycle governance have converged into one control problem.
Ghost logins expose the identity gap inside supposedly federated environments. A secure SSO route can coexist with an insecure local credential for the same user and the same app, which means the hidden path often matters more than the approved one. This is not a narrow MFA issue; it is a trust-boundary failure between identity provider policy and application-level authentication reality.
Identity assurance now depends on observed behaviour, not declared architecture. Cyber Essentials is effectively forcing organisations to prove that every in-scope account uses the protected path they claim to enforce. That aligns with the broader direction of identity governance: evidence must come from the live access surface, not from configuration intent or onboarding records alone.
From our research library:
- Across one million observed logins, 1 in 4 were password-based rather than SSO, 2 in 5 were not protected by MFA and 1 in 5 used a weak, breached or reused password.
What this signals
Identity assurance is moving from configuration proof to observed access proof. For teams running SaaS-heavy environments, that means browser-level visibility and account-level MFA verification matter more than a clean IdP diagram. The control objective is no longer just federation, but proof that every in-scope login path is actually protected.
Cyber Essentials 2026 is a preview of a wider governance shift. Compliance regimes are increasingly asking whether the organisation can see and govern the full identity footprint, not just the applications it formally onboards. For IAM and NHI programmes, that means shadow access and unmanaged credentials will stay material even where SSO coverage looks strong.
For practitioners
- Map the true SaaS access surface Build an inventory from observed browser logins, not only from the IdP application list, so shadow apps and alternate credentials are visible.
- Eliminate parallel login paths Review each in-scope app for local passwords, personal email sign-ins, and other fallback methods that can bypass the federated route.
- Verify MFA at the account level Check whether MFA is enforced on every account, not merely available in the tenant, and remove exceptions that leave ghost logins active.
- Extend governance to contractors and third parties Include externally managed users in the same login-path and MFA review because their accounts often sit outside normal onboarding and offboarding controls.
Key takeaways
- Cyber Essentials 2026 shifts the problem from proving that SSO exists to proving that every in-scope SaaS login path is protected and visible.
- Shadow apps and ghost logins are no longer edge cases when business accounts can access them outside the IdP boundary.
- The practical response is to govern observed logins, app-level MFA, and fallback credentials as one access control surface.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST CSF 2.0, CIS Controls v8, NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article focuses on weak SaaS login paths and MFA gaps across non-human and user-managed access. |
| NHI-10 — Human Use of NHI | Shadow apps and browser-native logins show how users bypass central identity controls in ways that resemble unmanaged identity use. | |
| Recommendation — Audit SaaS authentication paths for insecure fallback methods and enforce MFA wherever an app supports it. Map user-discovered apps and direct logins to the accounts they create and remove unsupported access paths. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The scheme now requires evidence that access permissions and authentication paths match policy across the full SaaS surface. |
| Recommendation — Validate that access permissions and authorizations align with the authentication method actually used for each in-scope app. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article turns account lifecycle and unmanaged account discovery into a compliance issue for SaaS estates. |
| Recommendation — Centralise account discovery and remove unmanaged SaaS accounts from the active identity estate. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | MFA enforcement and weak-password exposure make authenticator lifecycle governance directly relevant. |
| Recommendation — Enforce authenticator policy across every SaaS account and revoke any credential path that bypasses MFA. | ||
| NIST Zero Trust (SP 800-207) | Verify explicitly — Never trust, always verify | The article highlights the need to verify actual login behaviour instead of trusting SSO assumptions. |
| Recommendation — Verify each SaaS login path continuously instead of assuming federation covers the whole application estate. | ||
Key terms
- Ghost Login: A ghost login is a direct authentication path that remains active after an organisation believes it has moved to central single sign-on. It creates a parallel trust model that can still accept passwords, so the identity team sees one policy posture while attackers exploit another.
- Shadow app: A shadow app is an OAuth or GitHub App that exists in the environment without clear ownership or active oversight. These integrations are risky because they can retain broad permissions quietly, making it hard to judge whether the access is still needed or still appropriate.
- Authentication path: An authentication path is the route an identity uses to prove itself to a system, such as interactive login, LDAP bind, Kerberos ticket use, or service-to-service access. Many enterprises secure the credential but forget to govern every path that can still accept that identity.
- Attestation: Attestation is verifiable evidence about a workload’s execution context, such as where it is running, who started it, and whether it matches policy. In agent governance, attestation can be used to bootstrap enrollment and to justify access decisions that need to change as the workload behaves differently.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on June 10, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org