Two places data can be exposed
Data is at risk in two different situations. While it moves between devices, someone on the path might read or change it. While it sits in storage, someone who gets hold of the drive, card or backup might read it. Encryption can address both, but the two kinds of protection are separate, and having one does not give you the other.
Encryption means scrambling data with a key so that it is unreadable without that key. The details of the mathematics are not needed to use it well. What matters is knowing which threat you are guarding against and who holds the key.
Encryption in transit
“In transit” covers data travelling across a network, whether that is the internet, your home Wi-Fi or a short radio link. Without protection, anyone positioned along the route could in principle read or alter the messages. On a shared or public network, that can be a real concern. On your own wired network at home, the risk is smaller but not zero, especially once smart devices of uncertain quality are on it.
The most familiar form is TLS, the technology behind the padlock in a browser and the “https” in a web address. It does two jobs: it encrypts the traffic, and it lets the client check that it is talking to the genuine server through a certificate. The second job matters as much as the first. Encrypting a conversation with an impostor is not much help.
Other tools do a similar job for other protocols. SSH protects remote terminal sessions, and a VPN wraps traffic from a device inside an encrypted tunnel. Many sensor projects use MQTT messaging, which can be run with TLS and with usernames and passwords, though the defaults on some brokers are unencrypted and open. Web APIs normally should be called over https for the same reason.
Some points are worth remembering:
- Turn on encryption in the library or service settings instead of assuming it is on.
- Do not switch off certificate checking to make an error go away. That removes the part that stops impostors.
- Small microcontrollers may have limited memory and processing power for TLS. Check what a given board and its software support before designing around it, and consult the documentation.
- Some wireless protocols have their own link-level encryption, and its strength varies. It may not protect the data beyond the first hop.
Encryption at rest
“At rest” means data stored on a disk, memory card, phone, laptop, server or backup. The main threat here is loss or theft: a laptop left on a train, a card pulled from a camera, or a drive that was thrown away without being wiped. Encryption at rest means the person who holds the hardware still cannot read the contents without the key.
Common forms include full-disk encryption on computers and phones, encrypted containers or volumes for particular folders, and encrypted backups. A home NAS often offers volume encryption, and it is worth understanding the trade-off: if you lose the key, you generally lose the data too. Plan how the key or passphrase is stored, ideally in a password manager, with a recovery option kept somewhere safe.
On small devices, encryption at rest is harder. Many microcontroller boards store their programs and settings, including Wi-Fi passwords, in plain flash memory. Some chips offer features that encrypt flash or protect keys, but support varies a lot between parts, so check the datasheet rather than assuming. Often the practical approach is to keep as little sensitive data on the device as possible.
What each one does not protect against
Neither kind of encryption fixes everything.
Encryption in transit does not protect the data once it arrives. The server at the other end still has the plaintext, and whoever runs it can read it. Encryption at rest does not help while a system is running and unlocked, because malware or an attacker with a logged-in session sees the decrypted data. Neither stops a weak or reused password from letting someone simply log in.
Encryption also does not hide the fact that communication is happening, such as which servers a device talks to and roughly how much. That information can reveal habits even when contents are protected.
Keys are the real secret
Strong encryption rests on keys staying secret. A device that has its key written in the source code, or an API key committed to a public repository, undermines the whole arrangement. Treat keys and passphrases like the data they guard: store them separately, limit who can see them and change them if you suspect exposure.
Avoid designing your own scheme. Established protocols and well-reviewed libraries have been examined by many people, while home-made ones tend to contain mistakes that the author cannot see.
A sensible minimum for makers
For most projects, a reasonable baseline is: use encrypted connections for anything that carries logins or personal data, keep sensitive files and backups on encrypted storage, protect the keys with good habits, and keep software updated, because flaws in encryption libraries are fixed through patches. Match the effort to the data. Readings from a garden thermometer do not need the same care as camera footage or door-lock commands, though it is a good idea to build the habit anyway. No setup is guaranteed secure, but these steps cover the most common ways data leaks.