Guide · Request Verification
Verifying a law enforcement request means confirming three things independently before any data moves: the agency exists, the requester actually works there, and the request fits a legitimate pattern of investigative work. Most companies check none of them. The request arrives on official-looking letterhead from an official-looking address, and it gets worked. That held up for decades, and then criminals noticed. This page is the manual process, step by step, and it's honest about where the manual process stops scaling.
Because every other step in your response process executes faithfully on whatever gets past intake. Legal review checks whether the request is valid, not whether the requester is real. Production sends the data wherever the request said to send it. If the person on the other end is a criminal with a hacked police account, the rest of your process works perfectly on their behalf.
That's not hypothetical. Apple, Meta, Discord, and Verizon have all handed user data to criminals through forged emergency requests. In November 2024, the FBI warned that compromised government email credentials from more than two dozen countries were for sale on criminal forums, marketed for exactly this. How fake EDRs work. The short version: forged requests are now cheap, packaged, and sold as a service.
Verification is the one step positioned to catch them, because it's the only step that asks about the requester instead of the request.
Four things, each checked independently:
Independently is the operative word. Everything in the email, the domain, the signature block, the phone number, the letterhead, was put there by whoever sent it. Verification that relies on the contents of the request verifies nothing but the sender's effort level.
Start with a source that isn't the email. There are roughly 18,000 law enforcement jurisdictions in the US, plus foreign agencies, and no analyst knows them all. Check the agency against an independent registry or directory, never against the domain that contacted you. Lookalike domains are standard tradecraft, and even the real domain proves little: the FBI's 2024 advisory was about real agency accounts, compromised.
Call the agency's published main line, the number on its official website, and ask for the investigator by name. Never use the phone number in the request. Confirm they exist, that they're assigned to something resembling this matter, and that they sent this request. It takes minutes, and it defeats the entire category of attack where the sender controls every contact detail you were given.
Match the paperwork to the data being sought. In the US, a subpoena reaches basic subscriber information, a § 2703(d) order reaches records and metadata, and only a search warrant reaches content. The full process ladder. A request for message content on a subpoena isn't a paperwork error to fix for them. It's a signal.
Emergency data requests are the special case, because there's no paperwork to validate. Disclosure under 18 U.S.C. § 2702(b)(8) is voluntary and rests on your good-faith belief in the emergency. Good faith gets built the same way: a callback to the agency, a case number, incident details, a supervisor who confirms. If the emergency is real, thirty minutes of diligence doesn't change the outcome. If it isn't, it changes everything.
Is this the first time this requester has contacted you? Is the data scope consistent with the agency's mission and their history? A small-town department requesting records on accounts three time zones away deserves a harder look.
This is the step where a single company hits a wall. You can see your own request history; you can't see that the same account failed verification at three other companies last week. The patterns live across companies, and no one company's vantage point contains them.
Write down who checked what, when, and what they found: the registry consulted, the callback number used, who answered, what the supervisor confirmed. For emergency disclosures, this record is your good-faith basis. For declined requests, it's the reason your analyst gets backed up instead of blamed. Verification you can't evidence didn't happen.
Don't respond with data, and don't share your findings with the requester. Preserve the request and your verification record internally. Report it twice: to the real agency whose identity was borrowed, and to the FBI through IC3. Bring in counsel before any further contact. And if you're on a verification network, the failure travels: a requester who fails verification at one company has failed everywhere. What the network catches.
For a handful of requests a month, yes. The five steps above are a functioning manual program, and a disciplined small team can run them.
The math turns at volume. Verizon fielded more than 127,000 law enforcement demands in a single half-year; Coinbase reported 12,716 requests in its most recent reporting year. At that scale, minutes per request per step becomes headcount, and the pattern check never really works, because your vantage point is one company's inbox.
That's the problem Kodex removes. On Kodex, requesters are verified before they can submit: 15,000 government agencies and 150,000 investigators, each verified once, with behavior visible across every company they contact. Verification stops being a per-request project and becomes a property of the channel. Coinbase cut the time its team spent verifying law enforcement requesters by 99.9%. How requester verification works.
Have a request in front of you right now? Run it through Kodex Verify, free.
Is a .gov email address enough to verify a request?
No. Compromised government email accounts are the standard entry point for fraudulent requests; the FBI's November 2024 advisory documented credentials from more than two dozen countries for sale. The domain tells you where the email came from, not who wrote it.
How do you verify an emergency data request when there's no court order?
Through diligence that builds good faith: call the agency's published number, confirm the investigator and the case, get incident details, and have a supervisor confirm the emergency. Disclosure under § 2702(b)(8) is voluntary, so the decision is yours to make on the record you built.
Who should verify law enforcement requests?
The function that owns request response, usually legal, compliance, or trust and safety, following a written procedure. Verification decisions shouldn't rest on whoever happens to read the shared inbox that morning.
How long should verification take?
Manually, minutes to days per request depending on callbacks. On a verification network, effectively zero, because the requester was verified before they could submit anything.
Does verifying a request mean you have to comply with it?
No. Verification establishes who's asking. Whether and how to respond is a separate legal decision about the process itself.
.svg)
Secure, configurable, intuitive end-to-end platform that boosts performance, protection, and peace of mind.
