Security
Marine tech has had a free pass on security. Networks are flat, devices trust each other by default, and "secure" mostly means nobody has looked. I spent the last decade in software supply-chain security. I know what happens when you let that slide.
Security in 32°N isn't a feature you turn on. It's how every layer is built. Network locked by default. Every device authenticated before it connects. Every app signed and scanned before it gets installed. And a Marine Security Scanner that audits the whole thing on a schedule so you know when something changes.
Real threats · not abstract ones
These aren't hypothetical. They're the attack patterns I think about when I'm designing the platform — because they're real, they're documented, and marine gear vendors have mostly ignored them.
The Automatic Identification System — the radio protocol ships use to broadcast their position and identity — can be spoofed. A bad actor can broadcast phantom vessels to confuse traffic, or to lure a boat toward a false signal. AIS data should be treated as advisory, not authoritative.
Most NMEA-2000 gateways — the hardware bridges that connect your boat's instrument network to a computer — ship with default admin credentials and no prompt to change them. Half the boats in any marina have the same username and password on their gateway. I know because I've checked.
Multifunction displays (the chart screens at the helm) often run a web-based admin interface — sometimes on the boat's WiFi network with no authentication at all. A laptop on marina WiFi can sometimes reach them. Factory defaults are not security.
The boat's local network carries a lot: instrument data, course corrections, anchor alarms, crew comms. If that network isn't encrypted — or if every guest gets the same password that never changes — everything on it is readable by anyone nearby with a packet sniffer.
Plug-and-play firmware update workflows are common in marine gear: download a file, copy it to a USB stick, plug it in. There's typically no signature verification. A tampered firmware file served from a compromised vendor site installs just the same as a legitimate one.
An app you install on your boat's platform could itself be the attack surface — if that app was built with a compromised dependency, or if the distribution channel was tampered with. Most marine software has no app-signing or capability-auditing story at all.
Platform responses
Each threat above has a specific answer in the architecture. Not aspirational — these are decisions I've already made and built around.
The scanner surveys every device on your boat's network and flags anything unexpected — unknown devices, open admin panels, exposed services, changed configurations. It runs on a schedule so you find out when something changes, not just when you think to check.
Every build of 32°N is signed. Every app that runs on the platform must be signed by a registered author. The hub verifies the signature before installing anything. An unsigned or tampered package doesn't get through.
Mutual TLS (Transport Layer Security) means both sides of a connection — cloud and boat hub — verify each other's certificate before talking. A device pretending to be the cloud, or vice versa, fails the handshake immediately. No traffic reaches the hub from an unrecognised source.
Data stored on the hub — logbooks, routes, sensor history, vessel documents — is encrypted at rest. If someone physically gets access to the hardware, they still can't read the data without the key.
The keys that protect your data are yours. I don't hold a copy. If you self-host, everything stays on your infrastructure. If you use my hosted instance, you control the key material. No "premium decrypt feature."
The licence requires the full source to be public. Any security claim I make about 32°N can be independently verified by reading the code. You don't have to take my word for it. Researchers, crew, anyone with the skills can check.
32°N doesn't phone home unless you opt in. No silent analytics, no passive usage data collection, no "usage metrics to improve the product" running without asking. If you turn telemetry on, you can see exactly what gets sent.
The audit tool
The platform defaults keep things tight. But boats accumulate gear — a new chartplotter, a borrowed Starlink terminal, a temporary repair laptop left on the WiFi. The scanner finds what's there.
The scanner works in tiers. At the lowest tier it surveys the network passively — listing devices, noting open ports, checking for default credentials. At higher tiers it goes further: active probing, service enumeration, known-vulnerability checks.
You set the tier. You decide how aggressive the scan is and which subnets it's allowed to touch. The scanner won't touch a device you've excluded, and it won't go further than the tier you've configured.
Where a vulnerability is found, the scanner attempts to confirm it — not just flag it. A default-credentials gateway isn't just reported as a warning; the scanner tries the default password and tells you whether it worked. Findings are graded by confirmed severity.
The scanner has a command-line interface designed for running from a laptop on the same network as the boat — for the security-minded crew member or the owner who wants to check manually before plugging in something new.
Security center
Browse what the scanner already knows about, run a scan yourself from your laptop, leave the Hub scanning your boat automatically, or read the full threat catalogue. Pick the one that matches where you are.
Coordinated marine-security advisories — every CVE-style finding from the audits, with severity, target software, and a detail page per advisory. SignalK and OpenCPN ecosystems today; more as I work through them.
See the advisories →Install the scanner on your laptop and run it against your boat's network. Five minutes, no install on the boat itself. Curl one-liner for macOS, Linux, Windows. Findings keyed to the published advisory corpus.
Install the CLI →Install the 32°N Hub and every device on the boat's network gets scanned automatically, on a schedule. Findings show up on your boat dashboard. Conservative profile that's safe to leave running underway with autopilot engaged.
How auto-scan works →AIS spoofing, credential attacks, firmware tampering, network segmentation failures, supply-chain risk — with CVEs where they exist, real-world examples where they don't, and the scanner check that catches each one.
See the full threat list →Responsible disclosure
The fastest path is a private security advisory on GitHub. It reaches me directly, keeps the report private until a fix ships, and creates a permanent CVE record once it's resolved. This is the right channel for code vulnerabilities, dependency issues, and anything that needs coordinated disclosure.
If you'd rather not use GitHub, email security@32north.ai with your report. If the content is sensitive, please encrypt it to my public key. The fingerprint is:
F3A2 8B1C 4D96 E07F A21B 9C53 3E8D 0F6B 2A74 1E9D
Key available at keys.openpgp.org.
Describe what you found, how to reproduce it, and what impact you think it has. A proof of concept is helpful but not required. I'll respond to confirm receipt within two business days, and aim to ship a fix or mitigation within 90 days for confirmed vulnerabilities. I'll credit you in the advisory unless you prefer otherwise.
The platform monorepo (github.com/32north-ai/platform), the hosted 32north.ai service, the hub software, and any app distributed through the platform. If you're unsure whether something is in scope, send it anyway — I'd rather get a report that turns out to be a non-issue than miss a real one.
Denial-of-service attacks that require significant bandwidth, social engineering attacks against me specifically, or findings in third-party services (Supabase, GitHub, Netlify) that 32°N relies on. Report those to the relevant vendor directly.
AGPL-3.0 means the code that backs every claim on this page is publicly readable. Check it, audit it, challenge it.