Is a Duress Password Legal? The GrapheneOS Border Case
[image: 1785493938873-is-a-duress-password-legal-grapheneos-border-case.png]
Short answer: yes, having one is legal. Using one is where the risk starts.
No law bans a duress password. The software that offers the feature is legal to build, legal to publish, and legal to install. But a US traveler is now facing a federal charge because his phone allegedly erased itself in front of border officers who were about to seize it, and the government’s theory is that typing a passcode you set months earlier still counts as destroying property to stop a seizure.
That is a genuinely new legal question. It is also, for almost everyone reading this, the wrong thing to worry about.
Our guide to phone and laptop seizures at airports and borders opens with the fantasy most people carry through customs: “When shit hits the fan, I will just wipe all data off my device in front of the border agents.” This case is what that sentence looks like when someone actually does it.
What a duress password actually does
A duress password is a second unlock credential that destroys the device instead of opening it. GrapheneOS, the hardened Android build for Pixel hardware, documents it plainly: entering the duress PIN or password anywhere the system asks for your credentials “will irreversibly wipe the device (along with any installed eSIMs).”
Three properties matter.
It is silent. There is no confirmation prompt, no countdown, no way to take it back. The screen goes dark and restarts.
It is total. The wipe destroys the encryption key material, so the data is not deleted in a recoverable sense. It is mathematically gone, and the project has said publicly that there is nothing they can do to help anyone recover it.
It has a trap. If you set the duress credential to the same value as your real unlock, the real unlock wins and no wipe happens. GrapheneOS documents that too, and it is the kind of detail people miss when they configure a feature they hope never to use.
What happened at Hartsfield-Jackson
On January 24, 2025, Samuel Tunick, an Atlanta resident, landed at Hartsfield-Jackson on his way home from abroad. Customs and Border Protection pulled him into secondary inspection and pressed him to unlock his Google Pixel. According to reporting by TechCrunch, officers told him no warrant was needed because he had not yet crossed the border. He entered a passcode. The screen went blank, the phone restarted, and its contents were inaccessible. Officers seized the device and let him into the country.
Roughly eighteen months later, prosecutors charged him under 18 U.S.C. § 2232, the federal offence of destroying property to prevent a government seizure. The indictment says he “did knowingly destroy, damage, waste, dispose of, and otherwise take any action to delete the digital contents of a Google Pixel cellular phone, for the purpose of preventing and impairing the Government’s lawful authority.” He has pleaded not guilty. The maximum sentence is five years.
His defense argues the stop and the seizure were unlawful, that he was repeatedly refused access to a lawyer, and that the government was investigating his association with an Atlanta environmental protest movement rather than any crime. A ruling on the motion to suppress is not expected before late October 2026.
Everything above is allegation and argument. Nothing has been proven either way, and this article takes no position on whether he did what the government says.
Why the charge, not the search, is the story
Warrantless border device searches are old news. What is new is the theory attached to this one.
Section 2232 prosecutions are extraordinarily rare. Tunick’s public defender has said only one other case of this kind is publicly known, and it came out of a drug trafficking investigation. Applying it here means a court has to decide whether a preconfigured operating system feature, triggered by typing a string into a prompt, is the same kind of act as smashing a hard drive on a table.
If the answer is yes, then a setting becomes an offence at the moment you use it. That is the part worth watching, whatever happens to this defendant.
Your rights at the border are getting thinner, not thicker
The legal ground moved in the same month the case became public, and it did not move your way.
On July 13, 2026, the Fourth Circuit ruled in United States v. Belmonte Cardozo that a manual search of a phone at the border is a routine search, so officers need no warrant and no suspicion at all to scroll through it by hand. As the EFF explains, the court kept a higher bar for forensic extraction, which still requires individualized suspicion in that circuit, but drew the line so that a human thumbing through your messages counts as ordinary.
Other circuits disagree, and similar cases are pending elsewhere. The compelled-passcode question under the Fifth Amendment is separately unresolved, with courts split on whether making you type your own passcode is testimony. The practical result is that your rights at an airport depend on which airport it is, and on a body of law that is actively changing.
You cannot plan around that. You can only reduce what is at stake when it goes against you.
What GrapheneOS said, and what it pointed at
The project’s response was unambiguous on the law. It called the feature completely legal, said it has no obligation to weaken the protections it ships, and argued that being forced to do so would be unconstitutional.
Then it did something more interesting. Asked about the case, GrapheneOS mostly talked about everything except the duress password, calling it “only one component” of the security model and listing what actually does the work:
hardware-backed encryption with rate limiting enforced by the secure element
support for passwords up to 128 characters
automatic reboot back to the Before First Unlock state after a set period, 18 hours by default, adjustable from 10 minutes to 72 hours
USB set to charging-only while the device is locked, which is the shipped default
memory tagging and other exploit mitigations against extraction tooling
Read that list again. Not one of those requires you to do anything at the counter. They are all already running while you stand in line, exhausted, being asked questions by someone with far more power in that room than you have.
That is the whole argument, and the project made it without quite saying it.
Passive protection beats active destruction
[image: 1785493608645-screenshot-2026-07-31-at-12-25-44-is-a-duress-password-legal-the-grapheneos-border-case-privacytools.io.png]
The top three cost you nothing and are invisible. The bottom one is the only row on this table that has ever turned a bad afternoon into a prosecution.
A phone in Before First Unlock has never been unlocked since boot. Its keys are not in memory. It is the strongest state your device can be in, forensically, and reaching it costs one long-press before you join the queue.
So should you set a duress password?
This is not legal advice, and if you are in a situation where this question is live for you, the person to ask is a lawyer in your jurisdiction, before you fly rather than after.
With that said, an honest read:
If you already travel clean, it adds risk without adding protection. A device carrying nothing sensitive has nothing to destroy. You get the entire benefit of a wipe by simply not bringing the data, and none of the exposure.
Its real use case is coercion with no legal process at all. Robbery, kidnapping, a hostile actor with no warrant to seek and no court to answer to. In that scenario the calculus is completely different, and the feature is doing exactly what it was designed for.
The failure modes are worse than people expect. It is irreversible. It takes your eSIMs with it, which can leave you with no connectivity in a foreign country. Muscle memory under stress is unreliable, and the wrong finger on the wrong digit at the wrong moment ends the same way whether you meant it or not.
Having it set is not the same as using it. Nothing in this case suggests that configuring the feature is itself a problem. The alleged act was entering it after officers demanded access.
What to do instead
Do not bring the data. This is the whole game, and it is covered properly in the border seizure guide. Everything else on this list is a rounding error next to it.
Reboot before you reach the desk. One long-press puts the phone in Before First Unlock, which is free, invisible, and asks nothing of you later.
Shorten the auto-reboot window. If a device is seized while locked, a 30-minute timer means it locks itself down hard long before anyone gets it to a lab.
Leave USB on charging-only when locked. A plugged-in phone should not be able to talk to anything.
Use a password, not your face. The Fifth Amendment picture for memorized passcodes is contested but real. For biometrics it is considerably weaker, and a fingerprint can be taken from you without your cooperation.
If you run a hardened Android build as your daily driver, the same logic applies more sharply, not less. Read the full-disk encryption guide for what encryption at rest does and does not cover, and see our mobile operating systems picks if you are choosing a platform.
The lesson
The technical protections in a modern hardened phone are genuinely excellent. Against thieves, against remote attackers, against ordinary forensic tooling, they hold up.
What they cannot do is fix a legal problem. And the feature that gets the most attention, the one that promises you a way out at the last second, is the only one that asks you to make an irreversible decision at the worst possible moment, in front of the person you are trying to stop.
Privacy that depends on you performing correctly while frightened, jet-lagged and outnumbered is not a plan. It is a bet. The protections worth having are the ones already in place before you walk up to the desk, which is why the right time to think about any of this is when you build your threat model, not when someone asks for your phone.
