Why do DNS attacks still matter when organisations already use modern IAM?

Modern IAM still depends on DNS to reach login pages, token endpoints, certificates, and application back ends. If DNS is poisoned or spoofed, users and workloads can be redirected before IAM policy is even evaluated. DNSSEC reduces that redirection risk by authenticating DNS answers.

Why This Matters for Security Teams

Modern IAM is not a perimeter that starts at the login prompt. It depends on DNS resolution to reach identity providers, token services, certificate authorities, discovery endpoints, and the applications that consume those tokens. If DNS is spoofed or poisoned, an attacker can redirect a user or workload before authentication, MFA, or access policy ever has a chance to run. That makes DNS an identity dependency, not just a networking service.

This is why DNS attacks still matter even in environments with strong SSO and conditional access. NHI Management Group has repeatedly shown that identity failures often begin upstream of the credential check, as seen in the The 52 NHI breaches Report and the Ultimate Guide to NHIs. The same pattern appears in threat reporting from CISA cyber threat advisories, where infrastructure compromise is used to redirect trust rather than break it directly. In practice, many security teams encounter DNS abuse only after sign-in anomalies or token theft has already occurred, rather than through intentional DNS assurance testing.

How It Works in Practice

DNS attacks matter because identity workflows are chained together from multiple lookups. A browser or service resolves the IdP domain, fetches discovery metadata, validates certificates, and then exchanges assertions or tokens with downstream services. If any of those lookups are altered, the IAM control plane can be steered toward an attacker-controlled endpoint while still appearing “normal” to the user or workload.

For human users, this can mean credential phishing against a lookalike login page. For workloads and agents, the risk is more direct: poisoned DNS can redirect API calls, secret retrieval, webhook delivery, or OIDC discovery traffic to infrastructure that captures tokens or session material. This is especially relevant where Top 10 NHI Issues such as exposed secrets, weak token hygiene, and over-trusted automation already exist. The practical response is layered:

• Use DNSSEC where supported to authenticate DNS responses and reduce cache poisoning risk.
• Harden resolvers and recursive infrastructure, including access controls, logging, and monitored change management.
• Pin or validate critical identity endpoints where the application architecture allows it.
• Shorten secret lifetime and limit blast radius so redirected traffic does not expose long-lived credentials.
• Monitor for unexpected changes in IdP, CA, and token-service resolution paths.

There is no universal standard for DNSSEC adoption across all internal zones yet, so guidance suggests prioritising the identity-critical records first and extending coverage where operational ownership is clear. The broader risk picture is reflected in the 2024 Non-Human Identity Security Report, which shows that many organisations still struggle to match NHI governance maturity with the speed and complexity of modern access paths. These controls tend to break down when split-horizon DNS, legacy resolvers, or unmanaged third-party dependencies make identity resolution inconsistent across environments.

Common Variations and Edge Cases

Tighter DNS assurance often increases operational overhead, requiring organisations to balance authenticity gains against resolver complexity and zone-management burden.

Not every DNS attack has the same impact. For public SaaS identity flows, the main risk is redirection to a fake login or consent flow. For internal workloads, the more dangerous case is silent rerouting of token, certificate, or secret retrieval calls. In hybrid estates, split-horizon DNS can make validation uneven, so the same hostname may behave differently on-premises, in cloud networks, and on remote endpoints. Current guidance suggests treating those paths separately rather than assuming one control covers all.

DNSSEC is valuable, but it is not a complete identity control. It authenticates DNS answers; it does not guarantee that the destination service is trustworthy, that TLS is configured correctly, or that the application will detect a malicious but validly signed zone change. That is why identity teams increasingly pair DNS protections with certificate validation, workload identity, and real-time policy checks. The broader threat model is consistent with attacker tradecraft described in Anthropic’s report on AI-orchestrated cyber espionage and the MITRE ATLAS adversarial AI threat matrix, where attackers exploit system trust paths rather than individual credentials. DNS controls become weakest when legacy applications cannot validate endpoints, because the redirect itself becomes the compromise path.

Related resources from NHI Mgmt Group

• Why do AiTM attacks still matter if organisations already use MFA?
• Why do AI-driven phishing attacks still succeed when organisations use modern authentication?
• Why does DNS integrity matter to IAM and application security?
• Why do still-valid secrets matter after public disclosure?