Cyber Essentials 2026 expands the identity gap in SaaS access

At a glance

What this is: Cyber Essentials 2026 tightens cloud-service and MFA expectations, exposing gaps in SaaS visibility, shadow apps, and duplicate login paths.

Why it matters: It matters because IAM teams now have to govern the full long tail of business app access, not just the SSO-controlled core, across human and third-party accounts.

👉 Read Push Security's analysis of Cyber Essentials 2026 identity and MFA changes

Context

Cyber Essentials 2026 is best understood as an identity governance problem, not just a compliance update. The new scope reaches any cloud service accessed with a business email or account, which means the control boundary now follows real login behaviour rather than the services an organisation thinks it has standardised.

That matters because many enterprises still treat SSO coverage as proof of control. In practice, users self-adopt SaaS apps, keep local passwords active alongside federated logins, and create shadow access paths that auditors can surface even when the IdP dashboard looks clean.

For IAM and security teams, the change forces a broader view of human, contractor, and delegated account access across the SaaS estate. It also makes browser-level discovery and authentication telemetry relevant to lifecycle management, recertification, and MFA enforcement.

Key questions

Q: How should security teams handle SaaS apps that users access outside SSO?

A: Treat them as in-scope identity assets, not exceptions. Discover the app, identify every active login method, and decide whether the secure path can be made mandatory. If the application cannot enforce MFA or remove local credentials, it should be reviewed as a governance gap, not just an IT shadow app.

Q: Why do ghost logins create risk even when SSO is protected by MFA?

A: Because the secure SSO route does not eliminate the weaker local route. An attacker only needs one valid login path to reach the account. If users can still authenticate with an unprotected password, the stronger enterprise control exists beside, not instead of, the insecure one.

Q: What breaks when auditors find an app you did not know existed?

A: Your attestation evidence breaks first, because you can no longer prove the full in-scope population. Then your MFA and account lifecycle claims weaken, since the unseen app may have separate credentials, no central enforcement, and no offboarding process tied to your directory controls.

Q: Who is accountable when a contractor uses a shadow SaaS app without MFA?

A: The owning security and identity teams remain accountable if they cannot see, govern, and review that access path. In practice, the control failure sits at the boundary between access governance and application discovery, so contractor accounts must be covered by the same lifecycle checks as employees.

Technical breakdown

Why SSO dashboards miss real cloud access

A federated identity provider only shows part of the authentication picture. If an app supports both SSO and local credentials, the local path can remain active even when the organisation believes the app is fully governed. That creates a split identity surface: one control plane for the IdP, another for the application itself. Browser-native discovery exposes the actual login method used, which is why this class of compliance check now depends on observed access rather than configuration intent alone.

Practical implication: validate every cloud app against observed login behaviour, not just SSO configuration.

Ghost logins and concurrent authentication methods

Ghost logins are parallel authentication paths that survive alongside stronger enterprise login controls. A user can have an SSO session protected by MFA and a separate local password that is not protected the same way. Because many SaaS products allow multiple simultaneous login methods, security teams can end up with a secure path and an insecure path to the same account. That is a governance failure in account state, not simply a user error.

Practical implication: remove or disable local credential paths where SSO is required and supported.

MFA enforcement across the SaaS long tail

MFA enforcement becomes difficult when the product only offers it at a higher tier, allows self-adoption instead of admin control, or hides account-level configuration from administrators. Cyber Essentials now treats those exceptions as compliance-relevant because the control must exist on the actual login path, not just in policy. The technical issue is not whether MFA exists in the product. It is whether the organisation can prove it is enforced on every in-scope account and access route.

Practical implication: inventory MFA capability by app and subscription tier before certification evidence is collected.

Threat narrative

Attacker objective: The attacker wants to exploit the weakest available login path to reach cloud accounts without MFA and use them for theft or broader compromise.

1. Entry begins when an attacker uses leaked credentials against a cloud or SaaS account that still allows non-MFA access.
2. Escalation follows when the insecure login path bypasses the stronger SSO or IdP-protected route and grants direct account access.
3. Impact occurs when that access is used to steal data, move across cloud services, or operate undetected inside the organisation's app estate.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Snowflake breach — Snowflake breach compromised Ticketmaster, Santander and others via cloud credential abuse.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Shadow SaaS is now a governance problem, not an inventory problem: Cyber Essentials 2026 turns undiscovered applications into compliance failures because the test is based on actual access and actual MFA enforcement. The old assumption that the sanctioned app list represents the real identity surface no longer holds. Practitioners should treat shadow app discovery as part of access governance, not just app rationalisation.

Ghost logins expose a control-plane split that IAM programmes still undercount: A cloud app can be simultaneously governed by SSO policy and undermined by a surviving local password. That means the organisation has two truths for one account, and only one is usually visible in the IdP. This is exactly the kind of split that makes certification evidence fragile and attacker paths durable.

Compliance evidence must follow the login path, not the policy statement: The new scheme effectively rewards proof that MFA is enforced where users actually authenticate, including free-tier SaaS and contractor-held accounts. That breaks any programme that equates central SSO configuration with complete control. Practitioners should re-evaluate whether their attestation evidence reflects real user behaviour or only platform intent.

Browser-observed identity is becoming part of identity governance: The article shows why browser telemetry matters for app discovery, login-method detection, and MFA verification across unmanaged SaaS. The strategic shift is from trusting directory data to observing session behaviour. Teams that ignore this will continue to certify a partial identity estate while attackers exploit the unobserved one.

Identity assurance now extends beyond employees to every external access path: Contractors, third parties, and self-adopted tools all sit inside the expanded scope if they use business accounts. That widens the governance boundary from workforce SSO to the full delegated access chain. The implication is a lifecycle programme that can actually see offboarding, credential policy, and MFA posture across all access types.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
• That confidence gap shows why practitioners should also use Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs to align discovery, rotation, and offboarding across machine and delegated access.

What this signals

Shadow access is becoming the default audit failure mode: once certification scopes follow real login behaviour, the control problem shifts from policy alignment to identity discovery. The teams most exposed are those that rely on IdP dashboards as their source of truth instead of browser-observed authentication data.

Browser-level identity telemetry is now part of the NHI and human IAM conversation: the same discovery logic that finds hidden SaaS logins also surfaces unmanaged credentials, weak authentication paths, and contractor accounts. That makes the browser an enforcement point for both workforce governance and delegated access lifecycle control.

With 1 in 4 organisations already investing in dedicated NHI security capabilities, per The State of Non-Human Identity Security, the market is signalling that visibility and lifecycle control are converging across human and non-human identities.

For practitioners

• Map real SaaS usage against the certification boundary Capture browser-observed app usage, then reconcile it with your declared in-scope cloud list. Treat any app accessed with a business email or account as subject to review, even if it started as a free-tier or self-adopted tool.
• Eliminate duplicate login paths where SSO is mandatory Identify accounts that still allow local passwords alongside federated access, then remove the weaker path or force the stronger one. Focus first on high-value apps where a ghost login would bypass MFA.
• Validate MFA at the application layer, not just the IdP Check whether each SaaS service enforces MFA for every user, every subscription tier, and every login method. Where MFA is optional, hidden, or paid-only, treat that as an implementation gap for compliance and risk.
• Extend identity controls to contractor and third-party access Apply the same visibility and MFA checks to external users and non-managed endpoints, including dedicated contractor browser profiles where needed. Offboarding and recertification should include shadow apps and app-level credentials, not only directory accounts.
• Use the browser to detect shadow authentication behaviour Instrument the browser to surface hidden login methods, weak password reuse, and accounts that are not visible in SSO logs. Feed that data into recertification so the review reflects actual access paths rather than assumed ones.

Key takeaways

• Cyber Essentials 2026 raises the bar by judging cloud access on actual login behaviour, not just directory configuration.
• Shadow apps and ghost logins create a compliance gap because they let insecure paths survive beside protected SSO sessions.
• Teams need app-level visibility, MFA enforcement, and lifecycle controls that cover employees, contractors, and unmanaged SaaS alike.

Key terms

• Shadow SaaS: Software services used inside an organisation without formal approval or full visibility in central identity systems. Shadow SaaS often creates unmanaged authentication paths, duplicate credentials, and weak offboarding coverage, which turns ordinary app sprawl into a governance and compliance problem.
• Ghost Login: A secondary sign-in path that remains active alongside a stronger enterprise login method, usually local password access next to SSO. Ghost logins matter because they preserve a weaker route to the same account, which can defeat MFA and undermine certification evidence.
• Browser-observed identity: Identity data captured from the actual browser session, including app usage, login method, and authentication behaviour. This view is useful when directory logs are incomplete, because it shows how users really reach cloud services rather than how the organisation assumes they do.
• In-scope cloud service: Any cloud or SaaS application that falls within a compliance or governance boundary because it is accessed with business credentials. In this article's context, scope is determined by real access behaviour, not by whether the app was formally onboarded or centrally managed.

Deepen your knowledge

Cyber Essentials 2026, shadow SaaS discovery, and MFA enforcement are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a governance programme from a similar starting point, it is worth exploring.

This post draws on content published by Push Security: Cyber Essentials 2026 changes and what they mean for cloud access governance. Read the original.