Who is accountable when phishing infrastructure is used to steal credentials across multiple countries and sectors?

Accountability is shared across defenders, platform operators, and law enforcement, but the primary duty to protect users sits with the organisation that holds the accounts and data. Security teams must preserve evidence, coordinate with cloud and domain providers, and support civil or criminal action where appropriate. Cross-border abuse usually requires public-private coordination to be effective.

Why This Matters for Security Teams

When phishing infrastructure is used to steal credentials across countries and sectors, accountability becomes a chain of obligations rather than a single owner. The organisation that controls the accounts and data still holds the primary duty to protect users, but domain registrars, hosting providers, cloud platforms, and law enforcement each have distinct roles once abuse is detected. This is especially true when stolen secrets can be reused to pivot into email, SaaS, and infrastructure systems.

Security teams often underestimate how quickly a credential-theft operation becomes a multi-jurisdiction incident. A phishing kit can be cloned, shifted, and rehosted faster than a takedown request can move through legal channels. That makes evidence preservation, abuse reporting, and provider coordination just as important as reset actions. Guidance from the NIST SP 800-53 Rev 5 Security and Privacy Controls aligns with this operational reality because response obligations span detection, containment, and records retention. NHIMG research also shows that secret handling remains weak in practice, with 23.7% of organisations sharing secrets through insecure methods such as email or messaging applications, which increases the blast radius of a phishing event; see the Guide to the Secret Sprawl Challenge. In practice, many security teams encounter cross-border credential theft only after accounts have already been reused across several services.

How It Works in Practice

Accountability in these cases is distributed across operational control points. The victim organisation is responsible for securing accounts, resetting exposed credentials, and notifying affected users or regulators where required. Platform operators are responsible for enforcing abuse policies, preserving logs, and responding to credible reports. Infrastructure providers and registrars may suspend domains, IP space, or hosting, but they usually act on evidence and policy thresholds rather than on suspicion alone. Law enforcement becomes relevant when the activity crosses criminal thresholds, but coordination is often slow and uneven across jurisdictions.

Practically, a mature response starts with fast evidence capture: phishing pages, headers, URLs, certificates, DNS records, and authentication logs. Security teams should then coordinate with email, cloud, DNS, and hosting providers to disrupt delivery and reduce reuse of the infrastructure. This is also where identity hardening matters. The OWASP Non-Human Identity Top 10 is useful because stolen secrets often unlock non-human accounts, CI/CD systems, and API keys that attackers can repurpose beyond the initial phishing event. NHIMG case studies such as the Reviewdog GitHub Action supply chain attack and the Cisco Active Directory credentials breach show how exposed credentials can become a repeatable access path, not a one-time loss.

• Preserve logs before rotating credentials so attribution and scope can be established.
• Notify domain, hosting, and platform providers with concrete artefacts, not just abuse claims.
• Revoke sessions, tokens, and API keys, not only passwords.
• Check for reuse across email, SaaS, VPN, and automation systems.

These controls tend to break down when stolen credentials are shared across unmanaged SaaS tenants and self-hosted infrastructure because no single operator can see the full attack path.

Common Variations and Edge Cases

Tighter cross-border takedown and disclosure processes often increase coordination overhead, requiring organisations to balance speed against evidentiary integrity. That tradeoff matters because premature deletion can destroy attribution, while delay can allow reuse of the same phishing kit against additional sectors. Current guidance suggests that the most effective model is a public-private one, but there is no universal standard for this yet, especially where multiple privacy, cybercrime, and telecom regimes overlap.

Edge cases are common. If the phishing infrastructure is hosted in one country, registered in another, and used to target victims in several more, responsibility fragments quickly. The victim organisation still owns account protection, but platform operators may only take action after abuse thresholds are met, and law enforcement may need mutual legal assistance or sector-specific reporting channels. This is why security teams should treat phishing as an identity and infrastructure problem, not just a messaging problem. NHIMG’s Ultimate Guide to NHIs — Static vs Dynamic Secrets is relevant here because long-lived secrets increase the time window in which stolen credentials remain useful. In parallel, the NIST SP 800-63 Digital Identity Guidelines reinforce the need for strong assurance, lifecycle management, and recovery processes when identities are abused at scale.

Where this guidance breaks down most often is in highly decentralised environments with shared admin rights, weak logging, and no clear abuse-contact owner, because nobody can prove scope fast enough to drive coordinated response.

Related resources from NHI Mgmt Group

• Who is accountable when a compromised SaaS integration is used to move across multiple clouds?
• Who is accountable when shared credentials are used across teams?
• Who is accountable when compromised credentials are used to access personal or infrastructure accounts?
• Who is accountable when stolen credentials from a phishing email are used for fraud?