Cloud man-in-the-middle risk is moving inside the perimeter

At a glance

What this is: This is an Orca Security analysis of how man-in-the-middle attacks now target cloud API traffic, service-to-service calls, and Kubernetes communication paths.

Why it matters: It matters because IAM, NHI, and platform teams must treat traffic paths, certificates, and session tokens as part of identity governance, not just network hardening.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.

👉 Read Orca Security's analysis of cloud man-in-the-middle attack surfaces

Context

Cloud man-in-the-middle risk is no longer confined to Wi-Fi or rogue gateways. In modern environments, the interception opportunity often sits inside the estate, where service accounts, API calls, certificates, and session tokens move between workloads that teams assume are already trusted.

That assumption is weak once microservices, Kubernetes, and multi-cloud routing are in play. If TLS is misconfigured, certificate validation is loose, or network paths are over-permissive, an attacker can position themselves between identities and the data they exchange without breaking the application outright.

For IAM and NHI programmes, the problem is not only transport security. It is visibility into which identities can talk to which services, what tokens they carry, and how much blast radius exists if one path is intercepted.

Key questions

Q: How should security teams reduce man-in-the-middle risk in cloud environments?

A: Security teams should combine strong TLS, certificate validation, service-to-service authentication, and traffic segmentation. The key is to remove implicit trust from internal paths, because cloud MITM attacks often succeed inside the estate rather than at the edge. Teams should also monitor session tokens and workload identities, since intercepted credentials usually create the real blast radius.

Q: Why do service-to-service credentials make MITM attacks more dangerous?

A: Service-to-service credentials often carry broader permissions than a single user session and can unlock downstream APIs, data stores, or automation paths. If those credentials are intercepted, the attacker inherits the identity’s reach. That is why token scope, session lifetime, and identity context are as important as encrypting the transport.

Q: What breaks when internal TLS is weak or inconsistently validated?

A: Weak internal TLS allows attackers to downgrade encryption, substitute certificates, or exploit services that accept untrusted chains. In cloud-native systems, that can expose east-west traffic, internal APIs, and Kubernetes communications. The failure is not just confidentiality loss. It is the collapse of trust in the internal communication path.

Q: How do Zero Trust controls change the response to MITM risk?

A: Zero Trust changes the response by treating every connection as untrusted until it is verified. That means mutual TLS, certificate checks, least-privilege network paths, and continuous monitoring for drift. The practical benefit is smaller interception opportunity and smaller blast radius when a path is compromised.

Technical breakdown

How cloud MITM attacks exploit service-to-service traffic

A man-in-the-middle attack works by placing an attacker between two parties so traffic can be read, altered, or redirected. In cloud systems, the same pattern applies to east-west traffic, internal APIs, and service mesh communications, not just user logins. Misconfigured TLS, weak certificate validation, exposed listeners, and permissive security groups create the interception path. The attacker does not need to break encryption if they can downgrade it, substitute a certificate, or force traffic through a malicious intermediary. In Kubernetes and microservices, this often looks like trusted internal requests being silently rerouted.

Practical implication: validate internal traffic paths and certificate handling as part of workload exposure management, not only perimeter review.

Session tokens and workload identity expand the blast radius

MITM becomes more damaging when the target is not just data in transit but the identity artefacts carried in that traffic. Session cookies, API tokens, and workload credentials often prove that a service or user is already authenticated. If those artefacts are intercepted, the attacker inherits the access encoded in them, which may include broad cloud IAM permissions or service-to-service reach. This is why identity context matters: the same intercepted packet can be trivial or catastrophic depending on the privileges attached to the identity behind it.

Practical implication: reduce token lifetime and scope, and review which service identities can expose privileged downstream access if intercepted.

Zero Trust for cloud traffic requires continuous posture checks

Zero Trust reduces MITM opportunity by removing implicit trust from network location and internal routing. In practice, that means enforcing TLS 1.2 or 1.3, using mutual TLS where service-to-service trust matters, validating certificate chains, and segmenting traffic paths so not every workload can reach every other workload. Continuous posture management is the other half of the model because cloud environments drift. New services, copied rules, and default listeners can quietly reintroduce interception paths after they were once closed.

Practical implication: treat continuous posture checks as a control for reintroduced MITM exposure, not as a one-time hardening exercise.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

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

NHI Mgmt Group analysis

Cloud MITM is now an identity problem, not just a network problem. The article shows that interception risk follows the identity relationship, not only the packet path. When API keys, service accounts, and session tokens move through internal traffic, the attacker’s objective is often to hijack the identity context rather than simply read data in transit. Practitioners should treat network interception as a governance issue for workload identities.

Standing trust in internal traffic is the control assumption that breaks first. Internal services are often treated as trustworthy once they are inside the cluster or VPC, but the article shows that this premise fails when TLS is weak or paths are over-exposed. That assumption was designed for environments where route control implied trust. It fails when traffic can be redirected, downgraded, or intercepted inside cloud-native infrastructure. The implication is that internal trust boundaries need to be re-evaluated, not merely documented.

Identity blast radius is the metric that determines whether MITM matters operationally. A captured connection is only a meaningful incident if the associated identity can reach sensitive APIs, privileged workloads, or production data. That makes access scope, token lifetime, and downstream permissions more important than the interception event itself. Teams should evaluate MITM exposure by asking how far a stolen session or service credential can move.

Continuous posture management is the only viable baseline in dynamic cloud estates. The article’s prevention guidance reflects an operating reality: cloud routes, listeners, and certificates drift after deployment. A one-time TLS standard or network policy review cannot hold that environment steady. Practitioners need ongoing validation of traffic paths, certificate hygiene, and exposed services across the full workload lifecycle.

Correlating identity and network signals is the practical way to cut false positives. The article is right to connect traffic anomalies to identity and data context. A strange route matters more when it belongs to a workload that can touch secrets, payment flows, or administrative APIs. Security teams should prioritise detections that combine path changes with identity and sensitivity metadata.

From our research:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• For a deeper control baseline, review NHI Lifecycle Management Guide for provisioning, rotation, and offboarding discipline.

What this signals

Identity and traffic teams will have to converge around the same control plane. MITM defence in cloud environments now depends on seeing certificate state, network paths, and workload permissions together. That makes NHI visibility a prerequisite for practical Zero Trust, especially when service accounts and tokens are part of the interception path.

With 90% of IT leaders saying properly managing NHIs is essential for a successful zero-trust implementation, per Ultimate Guide to NHIs , Why NHI Security Matters Now, the operating question is no longer whether internal trust needs redesign. It is how quickly teams can map internal services to the identities they expose.

Identity blast radius: this is the practical measure that decides whether a network anomaly is noise or a real incident. If a captured path cannot reach privileged credentials or sensitive APIs, the event is lower priority. If it can, the response needs to be immediate and coordinated across IAM, network, and platform teams.

For practitioners

• Map internal traffic paths to identity scope Inventory which service accounts, pods, and API clients can reach sensitive endpoints, then tie each path to the permissions carried by the calling identity. Prioritise paths that can reach secrets, admin APIs, or production data.
• Enforce mutual TLS on service-to-service traffic Require certificate validation on both sides of internal calls and remove legacy or self-signed exceptions from service meshes, gateways, and internal endpoints. This closes the simplest downgrade and impersonation paths.
• Shorten token lifetime and narrow token scope Limit how long session cookies and API tokens remain valid, and constrain them to the smallest set of services or actions possible. Broad cloud IAM permissions make intercepted tokens disproportionately dangerous.
• Segment workloads that should never share a trust zone Use security groups and Kubernetes network policies to prevent low-value workloads from sitting on the path to high-value systems. A smaller reachable surface reduces the chance that an attacker can insert an intermediary.
• Run continuous checks for weak TLS and exposed listeners Scan for services listening on unexpected ports, TLS disabled on internal APIs, and certificate drift after deployments. Reintroduced exposure is common in cloud estates because copied configurations often inherit unsafe defaults.

Key takeaways

• Cloud MITM risk now lives inside east-west traffic, so internal trust assumptions deserve the same scrutiny as perimeter controls.
• The impact of interception depends on the identity attached to the traffic, which makes token scope and service-account permissions central to response.
• Teams that pair Zero Trust enforcement with continuous posture checks are better positioned to prevent reintroduced exposure as cloud estates drift.

Key terms

• Man-in-the-Middle Attack: A man-in-the-middle attack places an attacker between two communicating parties so traffic can be intercepted, changed, or redirected without immediate detection. In cloud environments, this can affect APIs, service meshes, and workload-to-workload calls, making transport security and identity context equally important.
• Mutual TLS: Mutual TLS is a communication method where both sides of a connection validate certificates before exchanging data. It helps prevent impersonation between services, but only when certificate chains are enforced consistently and exceptions are not left open in internal cloud paths.
• Identity Blast Radius: Identity blast radius is the amount of access an attacker gains if a session, token, or workload identity is intercepted. It is determined by permissions, token scope, and downstream reach, not by the interception event alone. Smaller blast radius means smaller operational damage.

Deepen your knowledge

Cloud man-in-the-middle risk and workload identity exposure are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for service-to-service traffic and token governance, it is worth exploring.

This post draws on content published by Orca Security: MITM Attacks and Orca Security. Read the original.