Who is accountable when illicit infrastructure services support sanctioned activity?

Accountability usually spans the service provider, the customer-facing platform, and the compliance function that failed to interrupt repeated high-risk access or transaction patterns. Frameworks such as NIST SP 800-53 Rev 5 Security and Privacy Controls and zero trust thinking both point to the need for clearer ownership, review, and boundary enforcement.

Why This Matters for Security Teams

When illicit infrastructure services support sanctioned activity, accountability is not limited to one team or one contract owner. Security, compliance, legal, fraud, and platform operations all share exposure if abusive tenants, automated workflows, or resold access are allowed to continue unchecked. The core issue is not just whether a service exists, but whether the organisation had enough control over onboarding, monitoring, escalation, and offboarding to stop repeated abuse.

That is why control ownership matters as much as control design. NIST SP 800-53 Rev 5 Security and Privacy Controls makes clear that accountability depends on defined responsibilities, auditability, and continuous monitoring rather than informal assumptions about who “should have noticed” the problem. Zero trust thinking reinforces the same lesson: trust is not granted because a user, customer, or partner relationship is established once. It must be re-evaluated as conditions change. See the NIST SP 800-53 Rev 5 Security and Privacy Controls for the control families most relevant to oversight, logging, and access enforcement.

In practice, many security teams encounter this only after sanctions violations, abuse complaints, or payment investigations have already exposed the gap, rather than through intentional preventive review.

How It Works in Practice

In operational terms, accountability should follow the control point that could have interrupted the activity. If a provider allows anonymous registration, weak identity proofing, or unrestricted API access, the provider may be accountable for failing to apply boundary controls. If a customer-facing platform keeps a risky account active despite repeated alerts, the platform owner and compliance function may share responsibility for not acting on those signals. If internal review processes exist but are not enforced, the failure is usually a governance failure, not just a technical one.

Practitioners should separate three layers of responsibility:

• Preventive controls: onboarding screening, identity checks, sanctions screening, entitlement limits, and approval gates.
• Detective controls: logging, anomaly detection, abuse monitoring, and case escalation for repeated high-risk behaviour.
• Corrective controls: suspension, offboarding, evidence retention, and post-incident review.

In a mature model, the service provider owns platform integrity, the customer relationship owner owns commercial escalation, and compliance owns policy interpretation and reporting thresholds. Zero trust architecture supports this by limiting implicit trust across users, services, and transactions, especially where high-risk behaviour can be automated at scale. For a practical control baseline, teams can map responsibilities to the relevant access, monitoring, and response controls in the NIST SP 800-53 Rev 5 Security and Privacy Controls and then document who acts, who approves, and who is escalated to when thresholds are crossed.

These controls tend to break down when responsibilities are split across subsidiaries, resellers, or outsourced operations because no single team owns the full decision chain from detection to suspension.

Common Variations and Edge Cases

Tighter accountability often increases operational overhead, requiring organisations to balance faster service delivery against stronger review, evidence, and escalation requirements.

There is no universal standard for this yet, so current guidance suggests using the clearest available ownership model rather than assuming shared responsibility will work in practice. In regulated environments, accountability may also extend beyond the immediate service provider to a platform operator, an intermediary, or a third-party processor if their controls materially enabled the sanctioned activity. That is especially true where contracts are vague, monitoring is shallow, or access can be reissued under a new identity with little friction.

Edge cases often involve machine-driven abuse, where bots or AI agents continue transactions after an account is flagged. In those situations, the accountability question should include whether the organisation had controls for identity continuity, privilege revocation, and automated decision review. If those controls are absent, the issue is not just misuse by the customer, but weak enforcement by the service owner. The practical test is simple: could the organisation prove who approved access, who monitored it, and who stopped it when risk became clear?

When those answers are unclear, accountability becomes shared in theory but disputed in reality, which is why audit trails and explicit escalation paths matter more than post-event blame assignment.

Related resources from NHI Mgmt Group

• Who is accountable when identity enrolment failures block access to public services?
• Who is accountable when a sanctioned remote worker is hired and paid?
• Who is accountable when privileged activity in virtualised infrastructure is not attributable?
• Who is accountable when sanctioned assets move through crypto infrastructure?