MITM attacks persist because trust checks still fail in practice

At a glance

What this is: This is a technical analysis of man-in-the-middle attacks and the implementation gaps that let them persist across apps, APIs, and network traffic.

Why it matters: It matters because MITM failures often expose credentials, sessions, and internal service traffic, which directly affects how IAM, NHI, and platform teams design trust boundaries.

By the numbers:

• According to the 2022 Cybersecurity Almanac, global cybercrime caused $6 trillion in damages in 2021 and is expected to rise to $10 trillion annually by 2025.

👉 Read WorkOS' analysis of man-in-the-middle attacks and prevention

Context

Man-in-the-middle attacks exploit a broken assumption in transport and identity security: that two systems are actually talking directly to each other. The primary keyword here is man-in-the-middle attacks, and the practical issue for IAM is that credential flows, session tokens, and service-to-service trust can all be intercepted if verification is weak.

The article shows that modern encryption alone does not eliminate the risk. Misconfigured TLS, skipped hostname checks, weak certificate handling, and insecure assumptions about internal networks still leave organisations exposed across human, NHI, and application paths.

For identity programmes, the key lesson is that trust needs to be explicit at every layer. That means certificate validation, token handling, and access boundaries have to be designed together rather than treated as separate teams or separate controls.

Key questions

Q: How should security teams prevent man-in-the-middle attacks in modern applications?

A: Security teams should enforce certificate validation, protect session tokens, and require encrypted service-to-service traffic by default. The key is to remove fail-open behaviour in clients and to treat internal traffic as potentially hostile. If a connection, token, or redirect can be intercepted and reused, the architecture still has an identity trust gap.

Q: Why do man-in-the-middle attacks still work in environments that use HTTPS?

A: HTTPS only protects traffic if clients verify the certificate and hostname correctly. MITM attacks keep working when applications accept invalid certificates, skip validation, trust internal networks too much, or allow token replay after interception. Encryption without verification prevents passive reading but does not stop active impersonation.

Q: What breaks when internal services assume the network is trusted?

A: When internal trust is assumed, attackers can use compromised devices, rogue access points, or DNS spoofing to position themselves between services. That can expose service credentials, tokens, and administrative traffic. The failure is not just technical exposure, but a governance model that treats location as proof of trust.

Q: How do organisations know if their MITM controls are actually working?

A: They should test whether clients reject invalid certificates, whether token replay is limited, and whether internal APIs still require explicit authentication over encrypted channels. If a service succeeds when certificates are wrong or if a stolen token remains usable for long periods, the control is not working.

Technical breakdown

TLS validation failures create the opening for MITM

A MITM attack succeeds when a client accepts a connection without properly verifying the certificate chain and hostname. That can happen through self-signed certificates, expired certificates, permissive library defaults, or development settings that never get removed. The attack is less about breaking encryption and more about exploiting the gap between encrypted transport and verified identity. When a client fails open, the attacker can proxy traffic, swap responses, and silently observe sensitive data. In practice, the control failure is not TLS itself but weak certificate enforcement across applications, mobile clients, and internal services.

Practical implication: enforce strict certificate and hostname validation everywhere, including internal APIs and non-production paths.

Session hijacking turns intercepted traffic into reusable access

Once an attacker can sit in the middle, the highest-value target is often the session token. Bearer tokens, cookies, and JWTs can be copied from traffic and reused to impersonate the legitimate user or service. This is why MITM attacks frequently become identity incidents rather than simple eavesdropping events. The design issue is that many sessions remain valid long enough to be stolen and replayed. Short token lifetimes, secure cookie flags, and sender-constrained patterns reduce that window, but the main lesson is that transport compromise becomes identity compromise almost immediately when tokens are reusable.

Practical implication: reduce token replay value by tightening session lifetime, storage, and transport controls.

Internal trust boundaries fail when the network is treated as trusted

The article makes a clear point that internal networks are not inherently safe. Compromised laptops, rogue wireless access points, malicious insiders, and DNS tricks can all place an attacker between services that assumed they were behind a trustworthy perimeter. That matters for IAM because machine-to-machine communication often inherits legacy trust assumptions from the network layer instead of proving identity at each hop. Zero Trust Architecture challenges that model by requiring continuous verification rather than network location as proof. The architectural failure is not just weak perimeter control, but identity decisions that depend on being inside the network.

Practical implication: require authenticated, encrypted service-to-service traffic instead of relying on internal network placement.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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

NHI Mgmt Group analysis

MITM attacks expose a transport trust problem, not a cryptography problem. The article is clear that attackers usually do not break TLS. They exploit misconfiguration, permissive defaults, and application logic that accepts unverified connections. The implication for identity governance is that trust in motion is only as strong as the weakest verification step, so transport and identity controls have to be governed together.

Certificate validation is a governance control, not a developer preference. Skipping hostname checks, accepting self-signed certificates, or leaving debug settings in production creates a repeatable trust bypass. That is a control-plane failure, because the organisation has allowed identity assertions to be accepted without proof. Practitioners should treat certificate policy enforcement as part of access governance, not just infrastructure hygiene.

Session hijacking is the identity consequence of a successful MITM path. Once a bearer token or session cookie is captured, the attacker no longer needs to stay in the middle to keep access. That makes token replay the practical business impact of the attack chain, and it shows why short-lived, tightly scoped sessions matter more than perimeter confidence.

Implicit trust in internal networks is a broken assumption, not a mature control model. Internal-only placement was designed for environments where network location carried more meaning than it does now. That assumption fails when laptops are compromised, DNS is poisoned, or microservices communicate across shared infrastructure. The implication is that identity programmes must stop using network adjacency as a proxy for trust.

Identity blast radius is the right concept for MITM-driven compromise. A single interception point can expose passwords, session cookies, API keys, and service credentials across multiple systems. That makes blast radius more important than whether the entry point looked minor. Practitioners should evaluate where a single transport failure would turn into enterprise-wide identity exposure.

From our research:

• Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging (37%) and over-privileged accounts (37%), according to The State of Non-Human Identity Security.
• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, with 38% reporting no or low visibility and 47% reporting only partial visibility.
• For a broader control lens, review The 52 NHI breaches Report to see how weak trust boundaries repeatedly turn into identity compromise.

What this signals

MITM risk is converging with identity governance because the same weaknesses that let traffic be intercepted also let credentials and tokens be reused. In practice, that means teams should evaluate transport security, token lifecycle, and internal trust boundaries as one programme, not as separate workstreams.

Transport trust debt: a system accumulates risk whenever it accepts connections or tokens without strong verification. The more internal services, mobile clients, and remote access paths that rely on permissive defaults, the more likely a single interception event is to become an identity incident.

For teams mapping this to standards, the alignment is straightforward: zero trust only works when every hop is verified, and NHI controls only hold when credentials cannot be stolen and replayed easily. See the NIST SP 800-207 Zero Trust Architecture model for the trust assumptions MITM attacks directly violate.

For practitioners

• Enforce strict certificate validation Remove any client-side settings that bypass certificate or hostname checks, including development defaults that can slip into production. Validate the full certificate chain and reject connections that do not match the expected service identity.
• Harden session tokens against replay Use short-lived access tokens, secure cookie attributes, and limited storage locations so captured traffic is less useful to an attacker. Avoid long-lived bearer tokens for high-risk workflows and review where tokens are exposed in logs or redirects.
• Treat internal traffic as untrusted Apply mutual TLS, authenticated service-to-service flows, and network segmentation to internal APIs and microservices. Do not rely on firewall placement or private addressing as proof that traffic is safe.
• Secure DNS and wireless entry points Use DNSSEC, protected resolvers, and enterprise Wi-Fi controls to reduce spoofing paths that enable MITM positioning. Review whether remote access and guest networks can be used to place an attacker between users and services.

Key takeaways

• MITM attacks remain effective because organisations still allow weak certificate checks, permissive defaults, and implicit network trust.
• The practical damage is identity-oriented: intercepted sessions, stolen tokens, and reusable credentials turn network compromise into account compromise.
• The limiting control is explicit verification at every layer, especially for internal APIs, session handling, and client-side TLS behaviour.

Key terms

• Man-in-the-middle attack: A man-in-the-middle attack is an interception pattern where an attacker positions themselves between two parties and can read, alter, or relay traffic without either side realising it. In identity terms, the danger is not only disclosure but also impersonation through stolen sessions, tokens, or certificates.
• Certificate validation: Certificate validation is the process of checking that a TLS certificate chains to a trusted authority and matches the intended hostname. In practice, it is a core trust decision, because accepting invalid or mismatched certificates lets an attacker impersonate a legitimate endpoint and intercept secure traffic.
• Session hijacking: Session hijacking is the reuse of a stolen session artifact, such as a cookie or bearer token, to act as an authenticated user or service. It turns intercepted traffic into active access and is especially dangerous when tokens are long-lived or not bound to the original client context.
• Zero Trust Architecture: Zero Trust Architecture is a model that assumes no network location is inherently trustworthy and requires explicit verification for every access request. For MITM defence, it matters because the network path itself is treated as untrusted, so identity and transport checks must be enforced continuously.

Deepen your knowledge

Man-in-the-middle attack prevention and trust verification are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your programme still treats transport security and identity governance separately, this course is a useful starting point.

This post draws on content published by WorkOS: What are MITM attacks and how to prevent them. Read the original.