Platform · Security
Marine tech has had a free pass on security for a long time. Flat networks, default credentials, no signing, no audit logs. I spent the last decade in software supply-chain security. I know what that slide looks like.
Security in 32°N isn't a feature added in a later release. It's in the architecture from the start. Default-deny network. Every device registered and authenticated. Every app signed and scanned. Continuous audit of everything that happens on the data bus.
Three pillars
Configure sets a known baseline. Detect finds drift and anomalies. Remediate closes the gap with actionable playbooks. All three have to work together or the security posture degrades over time.
Set a known-secure baseline and keep the boat on it. Default-deny local area network. Mutual TLS for every hub-to-cloud connection. Sandbox policy enforced from first boot. App permission model that makes undeclared access structurally impossible, not just discouraged.
Find drift the moment it happens. Signature-pack scanning for known-vulnerable firmware and software. Capability-mismatch detection when an app does something it didn't declare. Continuous audit log watching for access patterns that don't match the declared behaviour of anything on the boat.
Per-finding playbooks that tell you exactly what to do, and where safe to apply automatically without asking. The boat's Marine Security app can apply low-risk fixes on owner approval. Critical findings get a plain-English explanation, a severity rating, and a step-by-step fix.
Identity
Nothing connects to 32°N that hasn't been explicitly admitted. Owners, boats, devices, apps, and agents all have distinct identity records and distinct permission scopes. Revoke any one of them and access stops immediately.
| Entity | How it authenticates | Scope |
|---|---|---|
| Owner | Supabase Auth — email + passkey or OAuth | Full platform access on their boats |
| Boat | mTLS certificate, owner-signed | Named, registered, scoped to its own data |
| Device | Device registry, registered by owner | Scoped permissions; revocable at any time |
| App | Signed build, capability-token grant | Declared caps only; sandbox enforced |
| Agent | Same as app + AI gateway scoping | Declared tools + bus access only |
Code signing
Every build of the 32°N platform is signed. Every app that runs on the platform must be signed by a registered developer. The hub verifies signatures before installing anything. An unsigned or tampered package doesn't get through.
Mutual TLS
Mutual TLS (Transport Layer Security) means both sides of a connection — the hub on the boat and the cloud — verify each other's certificate before any data is exchanged. A device pretending to be the cloud fails the handshake immediately. A rogue hub pretending to be someone else's boat fails the same way.
The certificate chain is rooted in owner-controlled material. When a new boat is registered, the platform PKI (Public Key Infrastructure) mints a certificate for that hub signed by the owner's root. If the owner revokes the boat, the certificate is invalid and the hub can no longer talk to the cloud services.
Phones, tablets, and laptops that connect to the hub also go through device registration. Each device gets its own scoped certificate. If a device is lost or stolen, the owner revokes it from the registry and it can no longer reach the hub — even on the same local WiFi network.
Data protection
Two of the most important security components in the platform are both owner-controlled: the key store that protects data at rest, and the audit log that records everything that happens.
The keys that protect data stored on the hub are yours. I don't hold a copy. If you use the hosted instance, you control the key material and can export it or rotate it at any time. If you self-host, the keys never leave your infrastructure.
Data is encrypted at rest. If someone physically gets access to the Mac mini hardware, they can't read the stored data — logbooks, routes, sensor history, vessel documents — without the key.
No "premium decrypt" feature. No escrow. The licence prevents it structurally: AGPL-3.0 means the code that handles your keys is public and auditable.
Every action on the platform is recorded: who did what, when, from which device, and with which result. Bus reads, cross-app calls, network requests, blocked capability attempts, configuration changes.
The log is structured, queryable, and tamper-evident. Each entry is hash-chained so the log can't be silently edited after the fact. The whole log is exportable at any time — useful for insurance, for legal records, and for handing the boat over.
The Marine Security app can query the audit log for anomaly patterns — unexpected access times, capability attempts from apps that should be idle, device IDs appearing from unexpected network segments.
The bus is where everything in the platform flows — every sensor reading, every state change, every command. 32°N monitors the bus for patterns that don't match the declared behaviour of any registered device or app.
An unknown device sending AIS data. A known device claiming to be at coordinates it couldn't physically be at. An app sending commands to the bus at 3 a.m. with no active session. These are the anomalies the Watchman agent is watching for. Findings surface in the Marine Security app with context and remediation options.
All traffic between the hub and any connected device — phone, tablet, laptop, cloud services — is encrypted. There's no unencrypted communication path. WiFi traffic between your devices and the hub uses the standard WPA3 network and HTTPS for app layer communication.
The hub doesn't accept connections from devices that aren't registered. Even if someone is on the same marina WiFi as your boat, they can't reach the hub without being on the device registry.
Vulnerability response
I take security reports seriously. AGPL-3.0 means every claim on this page is publicly verifiable. If you find something that contradicts it, I want to know.
GitHub Security Advisories (preferred) or encrypted email to security@32north.ai. I acknowledge within two business days.
I reproduce the issue, assess severity, and scope the blast radius. I aim to have a fix or mitigation plan within 30 days for critical issues, 90 days for confirmed lower-severity ones.
The fix ships as a signed update through the normal release pipeline. Affected devices receive it through the standard update channel.
Once a fix is deployed, the CVE is published and I credit the reporter unless they prefer otherwise. The full disclosure includes the attack scenario and the mitigations.
Report via
GitHub Security Advisories
or email security@32north.ai.
For sensitive reports, encrypt to the key at
keys.openpgp.org.
Fingerprint: F3A2 8B1C 4D96 E07F A21B 9C53 3E8D 0F6B 2A74 1E9D
How it fits
Security is not a layer on top. It runs through all five layers of the platform — from the hardware on the boat up to the cloud services.
The security overview page covers the specific threat classes 32°N is designed to defend against — rogue AIS, default-credential gateways, firmware tampering, and more. The demo lets you explore the platform without any hardware.