Notifications
Clear all
Topic starter
09/06/2026 11:11 pm
TL;DR: Modern cloud environments expand man-in-the-middle risk beyond the perimeter into API calls, service-to-service traffic, and Kubernetes east-west paths, according to Orca Security. Zero Trust controls, certificate validation, and session-token protection now matter as much as encryption, because trust in internal routes is the real failure point.
NHIMG editorial — based on content published by Orca Security: MITM Attacks and Orca Security
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
What's in the full article
Orca Security's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step explanations of ARP spoofing, DNS spoofing, SSL/TLS hijacking, and session hijacking in cloud contexts
- Detection examples that correlate network anomalies with runtime behavior signals and identity context
- Prevention guidance for TLS 1.2 or 1.3, mutual TLS, certificate transparency, and network segmentation
- Product-specific attack path analysis and runtime telemetry details used by Orca Security
👉 Read Orca Security's analysis of cloud man-in-the-middle attack surfaces →
Cloud MITM attacks: are your identity and traffic controls keeping up?
Explore further
10/06/2026 1:26 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Cloud man-in-the-middle risk is moving inside the perimeter
