Who is accountable when a domain is hijacked?

Why This Matters for Security Teams

When a domain is hijacked, accountability is not just a technical question. It touches the registrar contract, DNS administration, identity and access controls, incident response, and legal notification obligations. Domain names are trust anchors for email, customer access, SaaS integrations, and certificate validation, so a takeover can turn one weak control into a broad business disruption. Current guidance from the NIST Cybersecurity Framework 2.0 treats governance and asset ownership as core security responsibilities, not side issues.

In NHI Management Group research, domain and credential abuse often shows the same pattern seen in the DeepSeek breach: once an external control plane is compromised, attackers move fast and the question becomes who had authority to prevent, detect, and reverse the change. That is why a domain hijack should be treated as a shared accountability event with named owners, not an after-action blame exercise. In practice, many security teams encounter the ownership gap only after DNS changes, registrar locks, or recovery requests have already stalled response.

How It Works in Practice

Accountability should be mapped before an incident across four decision points: who can approve registrar changes, who can authenticate emergency recovery, who can authorize communication to customers, and who can direct legal escalation. The registrar relationship owner usually holds operational authority, but security should own control verification, IT should own configuration recovery, and legal should own external notices when the domain supports regulated services or contractual commitments.

A practical model is to define the domain as a business-critical asset with explicit control boundaries. That means:

• Keeping registrar access behind phishing-resistant authentication and documented break-glass procedures.
• Separating DNS change approval from day-to-day administration, so a single compromised account cannot silently redirect traffic.
• Maintaining an offline recovery record for transfer codes, lock status, and authoritative contacts.
• Assigning a single incident commander for the domain event, even if multiple teams execute the recovery.

The reason this matters is that a hijacked domain can affect email deliverability, OAuth callback domains, certificate issuance, and user trust simultaneously. The State of Secrets in AppSec research shows how fragmented secret handling and slow remediation create long recovery windows, and the same operational weakness appears in domain control when ownership is diffuse. For policy and control mapping, the NIST Cybersecurity Framework 2.0 is useful for assigning governance, protection, detection, response, and recovery responsibilities across teams. These controls tend to break down when the registrar is managed by a marketing, product, or procurement function that lacks security escalation paths because response authority then arrives too late to stop transfer or DNS tampering.

Common Variations and Edge Cases

Tighter domain control often increases operational friction, requiring organisations to balance recovery speed against change approvals and separation of duties. There is no universal standard for this yet, so current guidance suggests tailoring accountability to the domain’s business impact rather than applying one rule to every registration.

For low-risk promotional domains, the registrar relationship may sit with marketing or web operations, but security should still define minimum controls and an escalation path. For authentication, payment, or customer portal domains, accountability should shift toward security-led oversight with IT operations executing approved changes. Legal becomes more prominent when a hijack could trigger breach notification, trademark disputes, or contractual service failures. In complex organisations, the best practice is evolving toward a RACI model that names one accountable executive, one technical owner, and one incident approver for transfer recovery.

Edge cases also matter. Domains held by subsidiaries, acquired brands, or external agencies often fail because no one can prove who has authority to reclaim the registration. The same risk applies when the registrar account is protected but the email mailbox used for recovery is not. That is why domain accountability should include both the domain record and the identity used to recover it. NHI Management Group research on DeepSeek breach reinforces a broader lesson: when control of a trust anchor is scattered across vendors and teams, the incident is already larger than the first team that notices it.

Related resources from NHI Mgmt Group

• Who is accountable when zero trust implementation lags behind identity growth?
• Who is accountable when a supplier identity is abused in a breach?
• Who is accountable when an MCP session misuses tools or data?
• Who is accountable when access governance gaps appear during digital transformation?