Notifications
Clear all
Topic starter
08/06/2026 4:45 pm
TL;DR: MITM attacks keep succeeding because many systems still trust insecure defaults, weak certificate validation, and internal networks too much, according to WorkOS. For IAM teams, the lesson is that transport security, token handling, and identity verification must be treated as one control surface, not separate problems.
NHIMG editorial — based on content published by WorkOS: What are MITM attacks and how to prevent them
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Enforce strict certificate validation Remove any client-side settings that bypass certificate or hostname checks, including development defaults that can slip into production.
- 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.
- Treat internal traffic as untrusted Apply mutual TLS, authenticated service-to-service flows, and network segmentation to internal APIs and microservices.
What's in the full article
WorkOS' full article covers the operational detail this post intentionally leaves for the source:
- Code-level examples of insecure TLS settings such as disabled certificate validation and unsafe redirect handling
- Step-by-step prevention checklists for developers and security engineers across web, mobile, and internal service flows
- Detection signs such as certificate warnings, rogue Wi-Fi behaviour, and suspicious DNS resolution patterns
- Practical configuration guidance for HSTS, mTLS, DNS hardening, and token handling
👉 Read WorkOS' analysis of man-in-the-middle attacks and prevention →
MITM attacks and TLS trust gaps: what IAM teams need to know?
Explore further
08/06/2026 6:33 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: MITM attacks persist because trust checks still fail in practice
