Identity attacks, session abuse, and vendor risk will dominate 2026

At a glance

What this is: The article argues that 2026 security will be shaped by identity abuse, trusted-session compromise, AI-accelerated attack speed, and runtime third-party risk rather than traditional malware-led intrusion.

Why it matters: IAM, PAM, and NHI teams need to treat post-authentication behaviour as an attack surface because valid access, not just broken authentication, is where breach paths are now forming.

By the numbers:

• Identity-based attacks will officially exceed 60% of all successful breaches.
• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.

👉 Read Exaforce’s 2026 security predictions on identity attacks, MFA, and third-party risk

Context

Identity attacks are becoming the primary security problem because attackers increasingly use valid credentials, trusted sessions, and native SaaS workflows instead of malware. In identity governance terms, that means the security boundary has moved from login to post-login behaviour, where access can look legitimate while still being abused.

This shift affects human IAM, NHI governance, and third-party access alike. Once a token, session cookie, OAuth grant, or service account is trusted by default, the key question is no longer whether authentication succeeded, but whether the resulting activity stays inside expected identity behaviour.

That is a familiar pattern for teams managing non-human identities, but the article extends it into mainstream enterprise security operations. The practical challenge is that runtime behaviour now determines risk faster than periodic review or static attestation ever can.

Key questions

Q: How can security teams tell whether adaptive MFA is working properly?

A: Look for a lower challenge rate on routine sessions, a higher challenge rate on suspicious transactions, and stable or improved conversion. If adaptive MFA is triggering everywhere, it is behaving like blunt MFA. If it rarely triggers on risky actions, the policy is too weak to matter.

Q: Why do trusted sessions create more risk than failed logins?

A: Because failed logins are noisy and visible, while trusted sessions let attackers operate inside normal workflows. A stolen cookie, OAuth token, or integration grant can move data and access without a new authentication event. That makes the breach path quieter and harder to distinguish from legitimate work.

Q: What do security teams get wrong about third-party access management?

A: They often focus on initial provisioning and underestimate the risk of stale access. The bigger failure is not granting access once, but failing to revoke it when the relationship ends or the business need changes. Without clear ownership and lifecycle triggers, third-party access quietly turns into standing privilege.

Q: Who is accountable when identity-based attacks move through SaaS integrations?

A: Accountability sits with the organisation that granted and failed to monitor the access path. Security, IAM, and application owners need a shared view of delegated scope, revocation ownership, and alert handling because third-party access becomes part of the internal identity model as soon as it is live.

Technical breakdown

Why trusted sessions have become the primary attack surface

Modern identity attacks exploit the gap between authentication and authorisation. A user can pass MFA, then have their session cookie, OAuth grant, or access token reused elsewhere without triggering a fresh login. In SaaS-heavy environments, that means an attacker can operate inside a valid session and move through approved workflows that security controls treat as normal. Endpoint tooling often misses this because no binary has to run and no exploit has to fire. The real failure is that session trust persists after the authentication moment. Behavioural monitoring is therefore more useful than gate-only validation.

Practical implication: monitor post-login activity continuously and treat session abuse as a first-class detection use case.

How SaaS-to-SaaS lateral movement changes identity governance

SaaS-to-SaaS lateral movement uses delegated permissions and integrations to move between cloud applications without direct human interaction. An OAuth app with excessive scope, a connected integration token, or a trusted third-party connector can become a bridge into sensitive data and administrative functions. This is structurally different from traditional lateral movement because the attacker rides sanctioned identity paths instead of creating new ones. Governance has to account for the effective reach of delegated access, not just the named user or service account that authorised it. That requires visibility into who can act through whom, and what the integration can actually do at runtime.

Practical implication: inventory delegated SaaS permissions and review third-party integrations as active identity paths, not static connections.

Why AI compresses detection windows across identity-led attacks

AI does not need to be autonomous to accelerate an attack. It can automate discovery, enumeration, credential testing, and privilege escalation fast enough to compress the time between initial access and impact. That changes detection from a batch problem to a streaming problem. Weekly scans and monthly hunts are poorly matched to activity that can complete in minutes or hours. For identity teams, the technical issue is not just speed but sequencing: once an attacker can pivot from login to exfiltration inside one short-lived session, the window for manual review effectively disappears. Automated containment becomes part of the detection model.

Practical implication: move identity telemetry into streaming detection and automate containment for abnormal high-speed access patterns.

Threat narrative

Attacker objective: The attacker aims to look like a legitimate user long enough to extract data, expand access, and avoid endpoint-based detection.

1. Entry occurs through valid credentials, stolen session cookies, OAuth grants, or trusted third-party access rather than through malware-led intrusion.
2. Escalation happens when the attacker abuses native workflows, reuses delegated permissions, and blends into approved SaaS activity to expand reach.
3. Impact follows when data exfiltration, lateral movement, or operational disruption completes before periodic controls detect the behaviour.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

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

NHI Mgmt Group analysis

Identity assurance at login is no longer a sufficient control boundary. The article is right that attackers now operate inside trusted sessions, which means authentication success does not equal security success. That breaks the old assumption that the front door defines the risk boundary. Practitioners should treat post-authentication behaviour as the real governance problem.

Trusted-session drift is the new control gap for human IAM and NHI governance alike. Session cookies, OAuth grants, and delegated tokens all create time-limited trust that can be misused without a fresh login event. The same pattern already exists in NHI environments, where a valid token can outlive its original context. Security teams need to think in terms of behaviour after trust is granted, not just how trust was issued.

Identity attacks surpassing malware changes where control value sits in the stack. Once valid access is the preferred intrusion method, EDR-only thinking becomes incomplete. The decision point moves to identity telemetry, privilege scope, and runtime behaviour, especially across SaaS and cloud. That is a stronger fit for IAM, PAM, and NHI governance than perimeter-centred models.

Runtime third-party risk exposes the weakness of static trust models. The article captures a broader shift from questionnaires and attestations to observed behaviour in production. That matters because third-party access is just another identity path once the connection is live. The practitioner conclusion is that governance has to follow the session, not the paperwork.

Identity blast radius is now the right named concept for 2026 planning. When attackers can move from one valid identity to many approved actions through tokens, integrations, and native workflows, the real question is how far that trust can spread before containment. That makes entitlement breadth, delegated scope, and revocation speed more important than isolated login hardening. Teams should measure blast radius, not just authentication strength.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• For a broader breach pattern view, 52 NHI Breaches Analysis shows how identity and secret exposure repeatedly turns into downstream compromise.

What this signals

Security programmes that still anchor on login success will miss the real problem, which is that attackers can live inside valid sessions long enough to move laterally and exfiltrate data. The operational response has to shift toward continuous identity telemetry, fast revocation, and tighter delegated access control across SaaS and cloud.

Identity blast radius: the amount of damage a valid account, token, or integration can cause before containment. As organisations add more SaaS and third-party connectors, the blast radius of a single compromised identity grows unless revocation and monitoring keep pace.

Teams managing machine access should also revisit the OWASP Non-Human Identity Top 10 because the same runtime trust problem is already well known in service-account governance. The lesson now extends to human identities and vendor integrations, not just workloads.

For practitioners

• Instrument post-authentication behaviour across SaaS and cloud Track what users and integrations do after login, including unusual exports, unusual admin actions, and cross-application activity that fits no normal baseline.
• Review delegated OAuth grants and third-party integrations Identify apps and connectors with excessive scope, stale ownership, or broad access to engineering, finance, or customer data.
• Shorten containment time for suspicious identity activity Define automated revocation paths for sessions, tokens, and linked accounts so abnormal behaviour can be blocked before lateral movement completes.
• Separate authentication assurance from authorisation trust Build alerts that trigger on contextually abnormal activity even when MFA succeeded, because valid login no longer proves safe behaviour.

Key takeaways

• Identity abuse, not malware, is becoming the dominant breach path because valid sessions and delegated access are easier to exploit than perimeter defences are to detect.
• The evidence points to a narrower response window, with attacker activity moving from initial access to impact faster than batch security processes can observe.
• Practitioners need to govern runtime behaviour, delegated scope, and revocation speed as core identity controls, not as downstream monitoring tasks.

Key terms

• Trusted Session: A trusted session is an authenticated access period that systems continue to regard as legitimate until it expires or is revoked. For human users, service accounts, and AI-driven workflows alike, a trusted session can become the vehicle for abuse if behaviour is not continuously evaluated.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

What's in the full article

Exaforce's full blog post covers the operational detail this post intentionally leaves for the source:

• The full explanation of each 2026 prediction, including the specific identity patterns behind the trend.
• Examples of the runtime behaviours security teams should watch for in SaaS, cloud, and third-party integrations.
• The article's own view of how compliance, SOC workflows, and incident response priorities are expected to shift.
• The closing operational framing on how to measure containment, trust, and behavioural drift in practice.

👉 Exaforce’s full post expands the prediction set into runtime monitoring, compliance shifts, and response implications.

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 building or maturing an IAM or identity security programme, it is worth exploring.