Somewhere in a federal court right now, prosecutors are trying to explain why a passcode is a crime. The defendant ran GrapheneOS, a hardened Android build popular with security researchers and journalists who travel through hostile jurisdictions, on his Pixel phone. Built into it is a duress feature: enter a specific code instead of your real unlock code, and the phone wipes itself. He used it at a U.S. border crossing. Now he’s being prosecuted for it. The case, first reported by Bruce Schneier, raises a question that has nothing to do with GrapheneOS and everything to do with how the rest of us think about cybersecurity: what happens when the exact feature you built to stop an attacker also stops an investigation you didn’t see coming?

A Border Crossing, a Blank Screen, and a Federal Charge

Border search law in the United States occupies a strange constitutional pocket. Officers there can search devices without a warrant, and the government has long argued the border isn’t quite U.S. soil for Fourth Amendment purposes until you’re formally let in. Handing over a passcode that wipes the device instead of unlocking it, in the government’s telling, isn’t a privacy safeguard. It’s obstruction. Whether that theory survives contact with a jury is a separate question from the one that matters to anyone running a security program: this feature exists because remote wipe, self-destruct triggers, and dead-man’s-switch style protections are standard defense in depth tools. Mobile device management platforms ship them. Encryption products build them in. Security teams recommend them without a second thought, right up until the moment the wipe fires against the wrong audience.

The Same Trigger Your MDM Policy Already Has

Strip the border politics out of it and you’re left with a familiar tradeoff. A lost laptop wipes itself after too many failed logins. A brute-force lockout policy nukes an account’s session keys after a threshold of bad attempts. A ransomware kill switch severs a host from the network the instant it sees encryption behavior that looks wrong. All of it is good security hardening, and all of it is designed to destroy something, access, keys, sometimes data itself, faster than a human can intervene. The problem is that automated destruction doesn’t know the difference between an attacker and your own incident response team trying to figure out what happened.

Analog Devices is living a version of that problem right now, minus the wipe. The semiconductor giant disclosed in a regulatory filing that intruders pulled data from its network earlier this summer, and weeks later the company still can’t say how much or what. That’s not incompetence. Scoping a breach honestly takes time, and it takes evidence: logs, forensic images, telemetry that survived the incident intact. Every hour spent reconstructing what an attacker touched is an hour where automated threat detection and containment tooling could just as easily have scrubbed the trail it was trying to protect. A wipe policy tuned purely for threat-protection, with no thought for what an investigator will need afterward, solves today’s intrusion and creates tomorrow’s blind spot.

Water Utilities Are About to Learn This the Hard Way

CISA just told the water sector, again, to lock down internet-exposed programmable logic controllers, days after intrusions hit dozens of Minnesota systems. That guidance is overdue and correct. But hardening the OT perimeter is only half of what these utilities are now legally on the hook for. Under CIRCIA, once the rule is finalized, covered water systems will have 72 hours to report a significant incident to CISA and 24 hours to report a ransom payment. Under AWIA, most systems already have to certify risk assessments that explicitly cover cyber threats, not just floods and equipment failure. None of that reporting works if the same aggressive isolation and lockdown measures utilities are racing to deploy also erase the logs, session data, and controller state that would let them explain what happened within a 72-hour window.

A segmented, isolated PLC that nobody can reach from the internet is a genuine win against a brute-force campaign or an opportunistic scan. But a utility that airgaps first and figures out logging second will find itself in the same bind as anyone whose wipe policy fired at the wrong moment: technically secure, and unable to prove it.

Building Defenses That Don’t Eat Their Own Evidence

None of this is an argument against aggressive automated response. It’s an argument for designing it deliberately instead of bolting it on. A few things worth doing before your own kill switch fires for the first time:

Separate what gets destroyed from what gets preserved. A wipe policy should nuke encryption keys and cached credentials, not the logging pipeline that tells you why it fired. Route security event data, firewall logs, authentication attempts, and controller state changes to storage the wipe trigger can’t touch, ideally somewhere immutable and off the device or host entirely.

Write down, in advance, who has authority to trigger destructive response and under what conditions, then test it in a tabletop exercise alongside your actual incident response plan. If your team has never rehearsed what happens when the automated containment step and the forensic step want to do opposite things at the same time, you’ll find out live, during a real incident, which is the worst possible time to learn.

Loop legal and compliance into that conversation before deployment, not after an incident. A destructive response policy that satisfies your engineers and blindsides your compliance officer is a policy that will get rewritten under pressure, badly, in the middle of a reporting deadline you’re already racing.

Finally, treat every lockout, wipe, or containment trigger as a logging event in its own right. If your firewall or brute-force protection layer disables an account or blackholes an IP, that action itself needs a timestamp, a reason code, and a durable record. The goal isn’t to weaken your defenses. It’s to make sure that when regulators, insurers, or your own team ask what happened, the answer isn’t “the system that stopped the attacker also erased the file that would have told you how.”

Sources

• American Being Prosecuted for Wiping His Phone Before Handing It Over to Border Officials
• Semiconductor chip titan Analog Devices reports data breach
• CISA Urges Water Sector to Protect OT After Coordinated Attacks on PLCs
• What water utilities need to know about cybersecurity compliance