18 U.S.C. § 2257 for platforms:
what the law actually requires

If you run a platform that publishes sexually explicit content, 18 U.S.C. § 2257 and its implementing regulations at 28 C.F.R. Part 75 impose federal criminal record-keeping obligations. They are old, they have been litigated for two decades, and they are widely misunderstood — usually in the direction of believing that the problem can be bought away.

It cannot. But a great deal of it can be made tractable, and knowing precisely which parts are which is the difference between a compliance programme and an expensive false sense of security.

Read that again if you have ever been told a vendor will “take the § 2257 obligation off your hands.” They cannot. What a good vendor can do is make your records complete, retrievable, durable and independently attestable. That is genuinely valuable. It is not the same as transferring liability, and any pitch that blurs the two should make you more cautious, not less.

Who the law applies to

The obligations attach to producers, and the regulation splits them in two. A primary producer actually creates the depiction — films it, photographs it, records it. A secondary producer publishes, inserts on a computer site or service, or otherwise manages the sexually explicit content.

Crucially, not every platform is a producer at all. Under 28 C.F.R. § 75.1(c)(4), the definition excludes activities that consist only of transmission, storage, retrieval, hosting, formatting or translation of a communication without selection or alteration of the content. A platform that curates, selects, or makes editorial decisions about explicit content is on very different ground from one that does not.

This is the first question to answer, and it is worth answering with counsel before anything else. Building a § 2257 programme for a platform that is excluded is wasted effort; assuming exclusion when you curate is considerably worse.

A note on the constitutional position

§ 2257 has been the subject of long-running constitutional litigation. In Free Speech Coalition v. Attorney General (3d Cir. 2020), the court held the age verification, record-keeping and labelling requirements unconstitutional as applied to the plaintiffs where performers were at least 30 years old, the government having conceded that at that age an adult performer could not reasonably be mistaken for a minor. The inspection regulation at § 75.5 has separately been held unconstitutional as applied.

That relief was as-applied, to those plaintiffs, in that circuit. The statutes remain on the books. The practical posture for a platform is to comply while recognising the area is unsettled — and to be sceptical of anyone selling certainty about it.

What a complete record actually contains

This is where most systems fall short, and the gap is structural rather than administrative. § 2257 records are kept per depiction, not per person.

Note the fourth and fifth rows in particular. The record contains a copy of the depiction and its URL. A system that captures identity beautifully but holds no link to specific content is not maintaining § 2257 records — it is maintaining identity records that a § 2257 record set would depend on. The distinction sounds pedantic until an inspection asks you to produce the record for a named title.

Six mistakes we see repeatedly

Where ProntoID fits — and where it does not

We will be direct about this, because the alternative is a sale that unravels in your counsel's first review.

ProntoID does not hold a complete § 2257 record set on your behalf. We verify identity and age against a government-issued document, retain a copy of the document examined, capture every alias, bind all of it to a sworn declaration under 28 U.S.C. § 1746, seal the result cryptographically and retain it for a minimum of seven years. We do not store the depictions themselves, and we do not maintain your per-title URL index. Those remain yours.

That is a deliberate architectural choice rather than a limitation we are apologising for. A verification provider that stored explicit content would become a host of that content, with every risk that follows. Binding records to content by reference keeps the evidence strong and the risk where it belongs.

The division is simple. If the person uploading is the only person depicted, an account-level release covers the identity, age and authorisation. The moment anyone else appears, that release no longer speaks for them, and you need a per-depiction record for that person instead.

The timing problem, and how to turn it around

§ 75.2(a)(1) requires that the identification card be examined prior to production of the depiction. This is easy to overlook and awkward once you see it: a verification performed when a user uploads is, for a primary producer, after the fact.

There are two honest responses. The first is to recognise that account-level verification fits the secondary producer route at § 75.2(b) far better than it fits primary production — that provision lets a secondary producer satisfy the requirement by accepting copies of the primary producer's records together with that producer's name and address.

The second is to make the timing constraint work for you. Once identity is verified and timestamped, you can refuse to register any content whose production date precedes that verification. Very few workflows can demonstrate, structurally rather than by assertion, that no content was ever accepted against an unverified identity. It costs one comparison and it is the kind of control that stands up when someone is actually looking.

Which documents count

One further trap. § 75.1(b) defines a picture identification card as one issued by the United States, a State, a political subdivision or a US territory. A foreign government-issued equivalent qualifies only where the performer is a non-US citizen located outside the United States at the time of original production and the producer maintaining the records is also located outside the United States on that date.

For a US-based platform this materially narrows the acceptable document set, and it is far cheaper to resolve before you build the capture flow than after.

Beyond § 2257

For most platforms we speak to, § 2257 is not the most pressing constraint. Two others usually bite sooner.

Payment scheme requirements

Card scheme rules for adult content merchants require documented age and consent verification for every person depicted, together with a documented takedown and complaint process. These are contractual rather than criminal, but the consequence — losing card acceptance — is immediate and existential in a way that a rarely-exercised federal inspection regime is not. In practice this is the deadline that concentrates minds.

The TAKE IT DOWN Act

Since 19 May 2026, covered platforms have had to provide a process for requesting removal of intimate images shared without consent, and to act on valid requests within 48 hours. The point that catches people out: a signed release is not a defence. Consent to publish is revocable, and a prior signature evidences what was authorised at the time rather than freezing that authorisation permanently.

This is why our release documents state expressly that withdrawal is available at any time, without reason and without charge, and that the sealed record survives withdrawal as evidence of what was authorised — but is never a basis to keep publishing. If a vendor's paperwork tries to indemnify you against the content subject's own removal request, that clause is likely unenforceable against a consumer and points in exactly the wrong direction.

A practical checklist

1. 1 Establish whether you are a producer at all. If you only transmit, store or host without selecting or altering content, § 75.1(c)(4) may exclude you. Do this first; the rest is wasted effort otherwise.
2. 2 Decide primary or secondary. Secondary producers may satisfy the requirement under § 75.2(b) by accepting copies of the primary producer's records plus that producer's name and address.
3. 3 Map every element of § 75.2 against what you actually hold today, including the copy of each depiction and its URL.
4. 4 Build the index before you need it. § 75.3 retrieval by any alias and by title is a schema decision, not a reporting feature.
5. 5 Segregate the record store. Separate location, separate access control, nothing else in it.
6. 6 Make retention a calculation, not a stored date, and recompute on every amendment.
7. 7 Resolve which identity documents qualify for your jurisdiction under § 75.1(b) before you design the capture flow.
8. 8 Write the § 75.6 statement with counsel, and make sure the address named is one where records can genuinely be produced.
9. 9 Have a removal process that meets the 48-hour TAKE IT DOWN Act window, and make sure a signed release never blocks it.
10. 10 Check your payment scheme obligations in parallel. They are usually the more urgent constraint.

If you would rather work through this as a list than as prose, our readiness checklist covers the same ground item by item, separating the gaps that are hard to explain later from the ones that are merely untidy.

Data protection pulls in the opposite direction to all of this — you are required to verify identity and required to hold less — and the two are reconcilable. Our guide to GDPR for content platforms covers how, and which parts no vendor can carry for you.

If you acquire content from other producers rather than shooting it yourself, the analysis runs through 28 C.F.R. § 75.2(b) instead — our guide to buying content and § 2257 covers what must be in the file you receive and what stays your responsibility.