A year after launch, the Nintendo Switch 2 still has no jailbreak, no custom firmware, no homebrew launcher. To us that isn’t a disappointment — it’s an interesting fact. Here is a commercial device that months of sustained community pressure haven’t managed to crack open. Nintendo isn’t relying on software alone: WebKit on the Switch 2 is hardened with ARM PAC, the boot chain has been reworked, and the new EULA reserves the manufacturer’s right to remotely block modified units. That makes the Switch 2 a genuinely useful reference model for what a platform designed with security from the ground up looks like.
So we didn’t go the route of modifying the console — on the Switch 2 that’s not just technically out of reach, it’s legally risky too. We stayed where testing is both legitimate and most instructive: at the network edge, with our own device and our own infrastructure. We mirrored traffic on the router, watched DNS, and controlled egress. The goal wasn’t to “get in” — it was to find out what the device reveals to an observer who can’t see inside it.
And the answer is good news for defenders: almost nothing useful. Practically all communication runs over TLS. At the network level we see destination domains and IP addresses, SNI, ports, TLS versions, and connection timing — metadata, in other words. The content stays encrypted. Decoding the payload would require getting the console to trust our certificate, which isn’t possible without tampering with the system — and on the Switch 2, it isn’t possible at all. Certificate pinning and an internal PKI do exactly what they’re meant to: even the device’s own owner, on their own network, can’t casually get at the plaintext.
That’s the bar. And this is where it becomes relevant to anyone building networked games. A few very concrete principles fall out of the observations: TLS everywhere, not just on login; pinning and client certificates tied to device identity, not a shared secret hardcoded into the client; telemetry and gameplay reports that can’t be trivially sniffed or spoofed; and an overall design that assumes from day one that the client is in adversarial hands. Most of the leaks we see in audits aren’t about broken cryptography — they’re about the client being forgotten as an untrusted party. The console doesn’t make that assumption, which is exactly why it holds up.
One more layer is worth calling out for game networking specifically: connectivity behind poor-quality NAT. The Switch’s online stack handles the case where two clients behind CGNAT can’t establish a direct connection, falling back to relay and STUN. If you don’t handle NAT traversal in your game, nobody pays for it but the players stuck behind an unlucky ISP — and it’s usually one of the first things that breaks in production, even when everything worked fine on a LAN in the lab.
There’s no point taking potshots at a hardened console. Studying it, though, is worthwhile — it shows exactly where the bar for network security sits when someone actually commits to clearing it.
Building a networked game or its backend and want to know what it looks like from an attacker’s vantage point at the network edge? Get in touch.