'Encrypted at rest' and 'encrypted in transit' are not the same claim

Vendors say 'we encrypt your data' as though it's one property, and it's actually at least two independent ones that protect against different threats, cover different parts of a system's life cycle, and can each be true, false, or — more often than buyers realize — true in a way that's technically accurate but practically meaningless.

In transit

Encryption in transit means data is encrypted while moving between two points — your browser and a server, one service and another, an agent and the platform it reports to. TLS is the standard mechanism, and it protects against an attacker positioned on the network path between those two points: a compromised Wi-Fi network, a malicious router, an ISP-level observer. It says nothing about what happens to the data once it lands. A perfectly TLS-encrypted connection can deliver data straight into a database storing it in plaintext.

At rest

Encryption at rest means data is encrypted while stored — on disk, in a database, in a backup file — such that reading the raw storage medium doesn't reveal the underlying data without the decryption key. This protects against a different threat: someone who gets access to the storage itself, whether that's a stolen disk, a database backup that leaks, or an attacker who's compromised the storage layer but not the application's decryption path. It says nothing about how the data got there or where it goes next.

Why the distinction matters practically

• A vendor can truthfully claim 'encrypted in transit' — true of nearly every modern web service using HTTPS — while storing everything in plaintext at rest, which is the more consequential gap for a database breach or a stolen backup.
• 'Encrypted at rest' can also be a weaker claim than it sounds if it means disk-level encryption only — protecting against physical theft of a drive — while the database itself and anyone with legitimate application access can still read everything unencrypted, which does nothing against a credential-based breach of the application layer.
• The strongest version of 'at rest' is field- or column-level encryption of sensitive data specifically, decrypted only at the point of use, which protects against a much wider range of compromise than disk encryption alone — and it's also the version of the claim a vendor is least likely to volunteer unprompted, because it's more work to build.

A vendor should be able to tell you, without hedging, which of these they actually mean for which category of your data, and a buyer should ask both questions separately rather than accepting 'yes, encrypted' as one answer to what's really two.

Where Nexus stands, specifically rather than generally: connections between the on-prem monitoring agent and the platform run over an authenticated encrypted channel, and every signed job is verified with Ed25519 before it executes — that covers transit and integrity together. At rest, integration credentials are encrypted under a platform secret key and are replace-only — there is no 'reveal' button anywhere in the product, for anyone, including our own staff — and student and guardian PII is encrypted at the data-store boundary rather than left to individual routes to handle correctly. That's field-level protection for the categories of data where it matters most, not a blanket disk-encryption claim standing in for the harder work. If a vendor's answer to 'encrypted at rest' doesn't specify which data and at which layer, that vagueness is itself the answer worth paying attention to.