Man-in-the-middle attacks expose why IAM needs stronger verification

At a glance

What this is: This is an explainer on man-in-the-middle attacks that shows how interception and spoofing can undermine logins, sessions, and data exchange even when users believe they are connected to a trusted service.

Why it matters: It matters because IAM, PAM, and NHI programmes often assume authentication proves trust, but MITM attacks show that transport, session, and endpoint verification all have to be aligned.

By the numbers:

• Estimates show that 35% of exploitation activity involves man-in-the-middle attacks.
• Nearly 58% of all posts on criminal forums and marketplaces contain banking data of others collected by MITM or other attack types.
• Business email compromise resulted in over $1.8 billion made by scammers in 2020.

Context

Man-in-the-middle attacks work by placing an adversary between a user and a trusted system so the attacker can intercept, alter, or replay communications without the user noticing. The primary governance problem is that authentication can succeed while the session itself is no longer trustworthy, which is why identity controls alone do not close the gap.

For IAM teams, the issue is not limited to passwords or login prompts. Session hijacking, DNS spoofing, Wi-Fi eavesdropping, and certificate abuse all show that trust has to be verified at more than one layer, especially where access to applications, financial data, or privileged systems is involved.

Key questions

Q: What breaks when man-in-the-middle protection is not in place?

A: When MITM protection is weak, users can authenticate successfully while an attacker silently intercepts the session, captures credentials, and reuses them against the real service. The break is not only the password exchange. It is the loss of trust in the communication path, which can lead to account takeover, payment fraud, or deeper network intrusion.

Q: Why do adversary-in-the-middle attacks still work when MFA is enabled?

A: Because the attacker does not need to defeat MFA directly. They relay the real login flow in real time, capture the valid session cookie after authentication succeeds, and reuse that cookie elsewhere. The control failure is at the session layer, where a trusted token outlives the original browser context.

Q: What are the signs that a session may be under MITM interception?

A: Common indicators include repeated login prompts, unexpected certificate warnings, suspicious DNS resolutions, mixed-content errors, and network traffic to unfamiliar intermediary IPs. None of these proves MITM by itself, but together they show that the trust path is unstable and should be investigated before users continue the session.

Q: Should organisations prioritise HTTPS, MFA, or certificate management first against MITM?

A: Start with certificate management and transport integrity for the services most exposed to interception, then layer MFA to limit credential reuse, and finally tighten user exposure to unsafe networks. The right sequence depends on which part of the trust path is weakest. If the channel is compromised, stronger passwords alone will not help.

Technical breakdown

How MITM interception works

A man-in-the-middle attack starts when the attacker positions a malicious endpoint, network path, or spoofed service between the user and the real destination. That can happen through rogue Wi-Fi, DNS spoofing, IP spoofing, or a fake website that looks legitimate enough to collect credentials or transaction data. The core mechanism is trust substitution: the user thinks they are speaking to the intended service, but the attacker is relaying or terminating the traffic. Because this sits at the transport and trust layer, the compromise can occur before application controls ever see an obviously invalid login.

Practical implication: validate the trust path, not just the login event.

Why sessions and cookies become high-value targets

Once an attacker has inserted themselves into the flow, session hijacking becomes one of the most dangerous follow-on outcomes because browser cookies, saved tokens, and login exchanges can be reused against the real service. This is why the article treats decryption and reuse as part of the attack chain, not a separate problem. A stolen session often bypasses password strength entirely, because the attacker is no longer trying to guess credentials. In IAM terms, the compromise has moved from authentication to bearer-token abuse, where possession is enough to act as the user.

Practical implication: treat session tokens as sensitive credentials with their own lifecycle.

Why certificate and HTTPS trust matter

MITM attacks often succeed by degrading or spoofing the encryption and trust indicators that users and systems rely on, such as HTTPS, SSL certificates, or S/MIME. If the certificate chain is weak, shared, expired, or improperly validated, the attacker can insert a malicious trust anchor and still present a believable connection. That is why the article highlights certificate management, encrypted email, and DNS over HTTPS as defensive controls. For identity programmes, the lesson is that identity proofing is incomplete unless the communication channel is also authenticated and protected.

Practical implication: enforce certificate hygiene and transport integrity as part of identity control design.

Threat narrative

Attacker objective: The objective is to capture trusted communications and turn them into account takeover, fraud, or a foothold for deeper intrusion.

1. Entry occurs when the attacker uses spoofed DNS, rogue Wi-Fi, fake websites, or IP manipulation to get between the user and the intended service.
2. Credential access follows as the victim enters usernames, passwords, or payment details into the spoofed or intercepted channel.
3. Escalation happens when the attacker reuses captured credentials or session data against the real application to change passwords, steal funds, or move deeper into the environment.
4. Impact is reached when the attacker uses that access for account takeover, unauthorized purchases, network penetration, or broader intrusion into company systems.

Breaches seen in the wild

• GitHub RSA SSH host key exposure 2023: GitHub.com's RSA SSH host private key was briefly exposed in a public repository; GitHub rotated it on 24 March 2023 and says there is no sign of abuse.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MITM exposes a trust-path problem, not just a login problem. Authentication can be perfectly valid while the connection itself is being intercepted, which means identity assurance must extend across DNS, certificates, transport, and session handling. That is why the control failure is not simply weak passwords or user error. The practitioner conclusion is that trust verification has to be continuous across the entire request path.

Session hijacking is the real identity break in many MITM cases. Once a bearer token or browser cookie is captured, the attacker often no longer needs to defeat authentication at all. This is a classic identity boundary failure because possession becomes sufficient for access, and the original user never sees a second challenge. The practitioner conclusion is that session state must be treated as a high-value credential, not just a convenience mechanism.

Certificate management is identity infrastructure, not background plumbing. The article’s examples show that shared, spoofed, or manipulated certificates can turn encryption from a protection into a false signal of trust. That makes certificate hygiene part of identity governance, especially where external users, SaaS platforms, and encrypted email are involved. The practitioner conclusion is that trust anchors deserve the same operational discipline as accounts and secrets.

Zero trust only works when transport verification is real. The article’s prevention guidance points to network segmentation, MFA, and HTTPS, but the deeper point is that zero trust assumptions collapse if the middle path can be silently altered. Strong identity controls cannot compensate for a channel that has already been hijacked. The practitioner conclusion is to align transport integrity, session control, and access policy as one governance model.

Identity teams should treat MITM as a cross-domain control test. This attack pattern sits at the intersection of IAM, PAM, secrets handling, and user trust, which is why it frequently survives narrow control ownership. A programme that only owns authentication will miss the channel, and a programme that only owns network security will miss token reuse. The practitioner conclusion is that MITM defence needs shared accountability across identity and infrastructure teams.

From our research library:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to the Ultimate Guide to NHIs.
• By 2029, 40% of enterprises that successfully implement zero trust within cloud service provider environments will rely on the advanced visibility and control capabilities offered by CNAPP solutions.
• Read next: Zero Trust Identity Guide

What this signals

Trust-path verification is the real control gap: if users can authenticate into a service that has already been intercepted, identity assurance has failed at the channel level even when the login itself succeeds. Teams should treat certificate validation, DNS integrity, and session binding as part of the access model, not separate network concerns.

MITM defence becomes more important as organisations expose more SaaS, remote access, and browser-based workflows, because those environments depend on trust signals that users rarely inspect closely. The practical shift is to assume that the credential is only one part of the attack surface and that the session, endpoint, and transport path all need control.

For practitioners

• Harden certificate validation Require strict certificate chain validation, monitor for expiry or unexpected issuer changes, and remove shared or weakly managed certificates from externally reachable services.
• Protect session tokens as credentials Shorten session lifetime where appropriate, bind sessions to stronger device or context signals, and revoke tokens immediately when interception is suspected.
• Reduce spoofing opportunities Use DNS over HTTPS, avoid insecure public Wi-Fi for sensitive access, and ensure critical applications fail closed when transport indicators are inconsistent.
• Add MFA as a second barrier Assume passwords and first-factor login can be exposed during interception, then require a second factor that limits the value of captured credentials.
• Segment sensitive access paths Separate high-risk systems and privileged workflows so a captured session cannot move laterally from a compromised login into broader internal access.

Key takeaways

• Man-in-the-middle attacks exploit the gap between authenticating a user and authenticating the path the user is using.
• The article cites 35% exploitation activity tied to MITM and more than $1.8 billion in business email compromise losses in 2020, showing that the pattern remains operationally relevant.
• Teams that want to reduce MITM risk need to align certificate management, session protection, and MFA rather than relying on a single control.

Key terms

• Man-in-the-Middle Attack: A man-in-the-middle attack is an interception technique where an attacker positions themselves between two parties that believe they are communicating directly. The attacker can read, alter, or replay traffic, which makes the attack especially dangerous when credentials, sessions, or certificates are involved.
• Session Hijacking: Session hijacking is the takeover of an authenticated session after the original login has completed. The attacker does not need to know the password if they can use the active session token, which is why session monitoring and revocation are essential controls in SaaS identity governance.
• 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.
• Transport Integrity: Transport integrity is the assurance that a client is talking to the intended server without interception or certificate spoofing. In administrative automation, this matters because an API token sent to the wrong endpoint can be captured or misused. Secure transport is part of access control, not just network hygiene.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.