Subdomain takeover risk exposes the DNS teardown gap teams miss

At a glance

What this is: FireCompass shows that subdomain takeover risk emerges when DNS records outlive the cloud, CDN, or hosting resources they once pointed to.

Why it matters: IAM and cloud security teams need to treat DNS teardown as part of offboarding and decommissioning because stale mappings can turn trusted domains into attacker-controlled entry points.

By the numbers:

• All 4 validated findings surfaced within the same quarter, 2026 Q2.

Context

Subdomain takeover is a lifecycle control failure, not a scanning problem. It happens when a subdomain still points to a cloud app, CDN mapping, storage bucket, or static-site host after that resource has been deleted or renamed, leaving the provider to treat the target name as unclaimed. In practice, the trust issue sits at the intersection of DNS hygiene, cloud offboarding, and domain ownership governance, which is why identity and access teams should care even when the weakness appears operational rather than purely IAM.

FireCompass’s analysis shows how often that teardown gap survives normal decommissioning. The article describes independent bug bounty assessments across multiple industries, with candidate issues validated through provider signals rather than live takeovers, which makes the pattern especially relevant for teams that run shared cloud services, delegated DNS management, or third-party hosting offboardings. This is a broad governance problem, not an isolated misconfiguration in one provider.

Key questions

Q: What breaks when DNS access is not tied to ownership and offboarding?

A: DNS governance breaks when former staff, contractors, or automation jobs still retain the ability to change zones or failover settings. Stale access makes it hard to prove who changed what and when, and it increases the chance of unauthorised changes during outages or incidents. Ownership and offboarding must be explicit for every DNS identity.

Q: Why does a claimable subdomain create more risk than a simple 404 page?

A: A claimable subdomain still sits under the company’s trusted namespace, so anyone who registers the released provider name can host content that looks formally legitimate to users and filters. That creates phishing, impersonation, and credential-harvesting risk even when the original application no longer exists. The risk is governance failure, not just service downtime.

Q: What are the signs that a subdomain takeover finding is real?

A: The strongest signs are provider-default not-found responses, an unclaimed resource name, and a DNS record that still points at a deleted or renamed external resource. If the provider itself indicates the name can be registered again, the exposure is materially different from transient outage. Teams should treat that as evidence of claimability, not scanner noise.

Q: How should teams govern subdomain takeover risk across cloud and CDN platforms?

A: Teams should govern it as a shared lifecycle problem across cloud, CDN, and hosting platforms, not as a separate check for each provider. The right control is a single teardown workflow that removes the resource and its DNS record together, backed by inventory and periodic validation. Ownership needs to follow the whole lifecycle, not just the live service.

Technical breakdown

How dangling DNS records become claimable subdomains

A subdomain takeover begins when DNS still points to a third-party service after the underlying resource has been removed. The provider then returns a default not-found or unclaimed-name response, which is not merely downtime but evidence that the original mapping no longer owns that name. If another account registers the same resource name on the provider, the new owner inherits control of what the subdomain serves. This is why subdomain takeover is really a domain lifecycle failure: DNS remains authoritative long after the backed resource has disappeared.

Practical implication: tie every DNS record to an owned lifecycle event so removal of the resource also removes the mapping.

Why provider error pages matter in takeover validation

A scanner can identify a dangling CNAME, but it cannot safely prove whether the target is truly claimable without checking the provider’s own signals. Default pages such as bucket-not-found, app-not-found, or unclaimed-domain responses indicate the provider no longer recognises an active owner for that name. That validation step matters because a subdomain takeover finding is about claimability, not just misrouting. The defender’s job is therefore to distinguish transient service failure from a name that has been fully released back into the provider namespace.

Practical implication: build validation checks around provider-specific not-found signals, not only around DNS resolution results.

Why teardown gaps spread across CDNs, cloud apps, and storage

The mechanics are consistent across provider types because the dependency is the same: a company-controlled DNS record points at an externally managed name. Whether the provider is a CDN, object store, app platform, or static host, the security mistake is treating provisioning and deprovisioning as separate workflows. Once the record survives the resource, the trust relationship survives too. That is why the issue can recur across unrelated business units and technologies even when each team believes it cleaned up its own asset.

Practical implication: inventory every subdomain by provider and lifecycle state so teardown gaps are visible across the full footprint.

Threat narrative

Attacker objective: The attacker’s objective is to take over a trusted subdomain and use the company’s domain authority to host malicious or misleading content.

1. Entry occurs when a company subdomain still resolves to a third-party resource that has already been deleted, renamed, or otherwise released by the provider.
2. Credential access is not the main stage here; the attacker instead claims the now-unowned provider name and inherits control of the mapping.
3. Impact follows when the attacker serves arbitrary content from a trusted corporate subdomain, enabling phishing, brand abuse, or credential collection under the company’s own domain.

Breaches seen in the wild

• Codefinger S3 ransomware 2025: Codefinger used victims' compromised AWS keys to re-encrypt S3 buckets with SSE-C, set 7-day deletion and demanded ransom for the key.
• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.

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

DNS teardown is the control gap, not subdomain discovery. The article shows that organisations can enumerate records correctly and still leave a takeover path open because decommissioning stops at the resource and never reaches the DNS layer. That is a governance failure across cloud, CDN, and hosting operations, not a scanning failure. Practitioners should treat DNS cleanup as a first-class offboarding control, not as post-script housekeeping.

Subdomain takeover is a trust-boundary problem that identity teams cannot ignore. Once a released provider name is re-claimed, the resulting content is delivered from a company-owned domain and inherits brand trust immediately. That makes the weakness relevant to IAM, PAM, and NHI governance because it sits at the boundary between delegated infrastructure ownership and externally visible trust. Teams that manage third-party access, hosting handoffs, or workload offboarding need to include DNS in the ownership model.

Claimability evidence is more important than scanner noise. FireCompass’s approach distinguishes a dangling record from a truly re-registerable name by validating the provider’s own signals. That matters because teams too often dismiss these reports as low impact when the real issue is that a trusted subdomain can be used for phishing, impersonation, or credential capture. Practitioners should prioritise lifecycle evidence over traffic volume when deciding exposure severity.

Cloud teardown discipline now extends into domain governance. The article’s recurring pattern across CDN, PaaS, object storage, and static-site platforms shows that the industry still separates infrastructure retirement from naming retirement. That separation creates accumulated risk across business units and providers, especially where DNS management is decentralised. The practical conclusion is straightforward: if a resource can be deleted, its DNS pointer must be deleted in the same control path.

Named concept: the DNS teardown gap. This is the failure mode where resource decommissioning is completed but domain teardown is omitted, leaving a live trust path to an unowned external name. It is a specific governance defect, not a generic availability issue, and it turns ordinary cleanup into an externally exploitable exposure. Organisations should make this concept visible in asset, hosting, and offboarding workflows so it can be governed explicitly.

From our research library:

• 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to the 2026 Infrastructure Identity Survey.
• Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption, according to the 2026 Infrastructure Identity Survey.
• Read next: Agentic AI Security Guide

What this signals

DNS teardown must become a governed lifecycle control, not a cleanup afterthought. The article shows that a live resource inventory is not enough if the corresponding subdomain record survives decommissioning. For identity and cloud teams, that means ownership models need to extend from access and provisioning into naming and offboarding, because claimable subdomains can undermine trust even when the original system is gone.

The DNS teardown gap is now a repeatable attack surface, not a one-off hygiene issue. FireCompass’s sample demonstrates that the same failure pattern can recur across CDN mappings, cloud app services, object storage, and static hosting. The practical signal for practitioners is clear: if teardown workflows are not integrated, risk will keep reappearing in different platforms under the same governance blind spot.

As static credentials remain common in agentic AI deployments, trust boundaries around external services become harder to defend, with 67% of organisations still relying heavily on static credentials despite the risks they pose to agentic AI deployments according to the 2026 Infrastructure Identity Survey. That exposure makes lifecycle discipline across DNS, secrets, and delegated access part of the same governance conversation, especially where external providers can outlive the service they supported.

For practitioners

• Make DNS removal part of offboarding Link resource deletion, renaming, and migration workflows to automated DNS record removal so the mapping cannot outlive the asset.
• Maintain an authoritative subdomain inventory Track every owned subdomain, its target provider, and its lifecycle state so stale records are obvious during decommissioning reviews.
• Validate provider-specific unclaimed-name signals Check for default not-found responses from CDN, cloud app, storage, and hosting providers before closing a decommissioning ticket.
• Review third-party domain delegation during offboarding Require handback checks whenever a team retires a hosted app, campaign site, or storage-backed service that was attached to a corporate domain.
• Escalate claimable subdomains regardless of traffic Treat a low-traffic but claimable subdomain as a trust-boundary exposure because the domain itself can be used for phishing or impersonation.

Key takeaways

• Subdomain takeover happens when a subdomain still points to a third-party service after the service has been deleted or renamed, leaving the provider name claimable.
• The article’s sample shows that independent programs can validate real takeover exposure even when the affected team later closes the report as informative or duplicate.
• The control that matters most is lifecycle linkage: resource teardown, DNS teardown, and validation of unclaimed provider names must happen together.

Key terms

• Subdomain Takeover: An attack in which someone claims or recreates a service behind a dangling subdomain and uses the trusted name to serve malicious content. The key issue is not the parent domain compromise, but the attacker inheriting trust through a stale pointer.
• Dangling DNS Record: A DNS record that still resolves to a target the organisation no longer controls. It usually points to a deleted cloud service, expired resource, or unused third-party endpoint. The record remains live even though the underlying asset has left the lifecycle.
• Provider-Default Not-Found Signal: A provider-default not-found signal is the error response a cloud, CDN, or hosting platform returns when a referenced name has no active owner. Security teams use it as evidence that a domain mapping may be claimable, not merely unavailable.
• DNS Teardown Gap: The DNS teardown gap is the governance failure that occurs when a resource is decommissioned but its DNS record is left behind. It turns cleanup into an externally exploitable trust path because the subdomain continues to resolve even after the backing service is gone.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, machine identity security, and secrets management. It helps practitioners connect lifecycle control, trust boundaries, and delegated access across identity-heavy security programmes.