Q3 2025 incident trends show identity attacks dominating operations

At a glance

What this is: Expel’s Q3 2025 incident review shows identity-based attacks dominating SOC investigations, with compromised credentials and secret key exposure driving most of the cloud-related activity.

Why it matters: For IAM, PAM, NHI, and cloud security teams, the finding reinforces that access governance, credential lifecycle, and secret handling are now core operational controls rather than supporting hygiene.

By the numbers:

• Identity-based attacks comprised almost three-quarters (73.9%) of incidents the SOC investigated.
• Compromised credentials accounted for 54.9% of cloud-service incidents.
• Secret key exposure reached 26.8% of cloud infrastructure incidents.
• The cloud infrastructure category represented around 1.1% of total incidents.

Context

Q3 2025 incident data points to a governance gap rather than a new class of attack technique. When most incidents begin with credentials, email compromise, or exposed secrets, the effective control boundary sits inside identity lifecycle, authentication, and secret handling.

This report matters because the same attacker objective shows up across cloud services, business applications, and infrastructure: gain trusted access, then use it before controls can contain the session. For NHI programmes, the parallel is direct, since leaked keys and service credentials behave like unmanaged identities once exposed.

Key questions

Q: What breaks when identity attacks dominate incident volume?

A: Security teams lose the ability to rely on perimeter-first thinking because the attacker’s entry point is already trusted access. When most incidents begin with credentials, login compromise, or secret exposure, the failure is usually in identity lifecycle, authentication strength, or revocation speed rather than in malware detection.

Q: Why do compromised credentials keep showing up in cloud incidents?

A: Cloud services are built to trust authenticating identities, so stolen credentials often look legitimate until they are used in ways that violate normal behaviour. If organisations do not narrow permission scope and continuously validate sessions, the same credential can be reused across multiple business services before defenders notice.

Q: How do security teams know whether secret management is actually reducing risk?

A: Look for fewer reusable credentials, shorter credential lifetimes, and a lower number of systems that still depend on manually rotated secrets. If the environment still depends on stored tokens for routine workload access, the programme is managing exposure, not removing it.

Q: When should organisations separate human and machine identity controls?

A: They should separate them as soon as service accounts, API keys, or cloud tokens carry meaningful access, because machine identities fail differently from user accounts. Human login controls do not prevent a leaked application key from being replayed, so the lifecycle and monitoring model has to change.

Technical breakdown

Identity-based incidents now dominate initial access

Identity-based incidents dominate because access is the easiest trusted path into cloud and business systems. Attackers prefer credentials, login sessions, and email identities because these already sit inside the organisation’s trust boundary. Once a username and password, token, or session are accepted, defenders often see normal-looking activity rather than obvious malware signals. That makes authentication strength, conditional access, and lifecycle controls more important than perimeter blocking alone. The data also shows that organisations are blocking a meaningful share of attempted credential use before compromise, which means the control layer is working unevenly rather than failing completely.

Practical implication: Treat identity telemetry as a primary detection surface, not just an audit trail.

Why secret keys behave like non-human identities

Secret keys in cloud infrastructure act like non-human identities because they authenticate systems, workloads, and applications rather than people. When a key is hard coded into source code, embedded in an application, or recovered from malware, the attacker inherits whatever access scope the key carries. Unlike a human account, a leaked key often has no immediate user lockout signal and may remain valid until it is rotated or revoked. That makes inventory, ownership, rotation, and scoped permissions central to preventing abuse. In practice, exposed secrets often outlive the event that leaked them.

Practical implication: Inventory every cloud secret and bind each one to an owner, a purpose, and a rotation schedule.

Attack surfaces fail differently, so controls must be segmented

The report makes a useful distinction: cloud services fail through identity misuse, endpoints fail through malware, and cloud infrastructure fails through misconfiguration or exposed secrets. Those are not interchangeable problems, so a single control strategy will leave gaps. Identity tooling may reduce account takeover without limiting a hard coded access key. Endpoint protection may detect malware without preventing secret theft from code or logs. The governance lesson is that control design has to follow the attack surface, not the security team’s preferred tooling model.

Practical implication: Map each asset class to its own control set instead of relying on one defence pattern for all incidents.

NHI Mgmt Group analysis

Identity telemetry has become the real front line for incident triage. When 73.9% of SOC-investigated incidents are identity-based, the security problem is no longer just whether an account was breached. It is whether authentication, session handling, and identity lifecycle controls can distinguish normal access from attacker use quickly enough to matter. Practitioners should treat identity events as operational control signals, not just investigation artefacts.

Secret leakage is the clearest non-human identity governance failure in cloud operations. A hard coded key is not just a secret management issue, it is an unmanaged machine identity with standing authority. Once exposed, the key can be replayed without the human friction that often exposes account compromise, which is why ownership, rotation, and revocation need to be lifecycle controls rather than cleanup tasks. Practitioners should govern cloud secrets as identities with explicit lifecycles.

Attack-surface-specific defence is now a governance requirement, not a maturity preference. The report separates endpoint malware, cloud service identity abuse, and cloud infrastructure secret exposure into distinct incident patterns, and that distinction matters. A team that only tunes for one attack surface will miss the others because the failure modes are different. Practitioners should segment controls by surface and align detection, response, and review processes accordingly.

Identity and secret governance is now a board-level exposure metric. The clearest strategic signal in the report is that access material, not exploit complexity, determines whether attackers get in. That shifts the governance question from how many controls exist to whether credentials, tokens, and secrets are discoverable, revocable, and bound to actual business ownership. Practitioners should report identity exposure as an operational risk indicator, not a backend admin problem.

What this signals

Credential exposure is now an operational reality, not a hypothetical control gap. Teams should expect attackers to test identity material first and design containment around revocation speed, scope reduction, and visibility into blocked use. Where identities are central to service access, response quality depends on whether the organisation can invalidate trust quickly enough.

Machine identity governance is the underused control layer in cloud incident reduction. A cloud secret is only safe if it has an owner, a purpose, and a lifecycle that is enforced independently of application deployment. That means cloud security teams and IAM teams need a shared view of secrets as governed access objects, not just as configuration artefacts.

Access governance has to become surface-specific. Endpoint, cloud service, and infrastructure incidents now show distinct failure modes, so the same prevention pattern will not cover all exposure paths. Practitioners should align review cycles, monitoring thresholds, and revocation processes to the attack surface that actually fails.

For practitioners

• Implement separate control plans for each attack surface Build different playbooks for identity-based attacks, endpoint malware, and cloud infrastructure exposure so detection and response do not assume one control pattern fits all incidents.
• Tighten cloud credential lifecycle controls Inventory cloud keys, tokens, and service credentials, assign ownership, and require rotation or revocation paths that work even when the original issuance system is unavailable.
• Reduce standing trust in login and API access Limit how long credentials remain valid, narrow the permissions they carry, and validate that failed and blocked access attempts are visible to the teams responsible for response.
• Separate human and machine identity governance Treat service credentials, application secrets, and user accounts as distinct control populations with different review, revocation, and monitoring requirements.

Key takeaways

• Identity-based attacks dominated the quarter’s SOC activity, showing that trusted access paths remain the easiest route into enterprise environments.
• Cloud infrastructure risk was shaped less by scale than by access material, with secret exposure and unauthorized access driving the category’s most important failures.
• Security teams need separate control strategies for identities, endpoints, and cloud secrets because the same defensive model does not address all three attack surfaces.

Key terms

• Identity-based threat: An identity-based threat is an attack that abuses legitimate credentials, sessions, or account permissions rather than breaking into the network first. It succeeds by looking like normal access while the attacker steals data, moves laterally, or escalates privilege.
• Secret Key Exposure: Secret key exposure occurs when a credential that authorises access to a system becomes visible to an unauthorised party, often through code, logs, misconfiguration, or malware. Because many cloud secrets are bearer credentials, exposure can create immediate operational risk unless the secret is revoked or replaced quickly.
• Cloud infrastructure unauthorized access: Cloud infrastructure unauthorized access is entry into cloud-hosted systems without approval, usually through misconfiguration, vulnerability abuse, or exposed access material. The risk is not just reading data, but obtaining a foothold that can be expanded through permissions, automation, or persistent credentials.
• Credential Lifecycle Governance: Credential lifecycle governance is the set of controls that manage creation, assignment, monitoring, rotation, and retirement of credentials. For machine identities, it prevents secrets from becoming permanent access artifacts and ensures every identity has a defined owner, purpose, and end state.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It helps practitioners build the governance foundations needed to manage machine identities, secrets, and access lifecycles across modern environments.