AES-256 and TLS 1.3 Explained · How Your Data Is Actually Protected
Every security page promises AES-256 and TLS 1.3. Here is what those two standards actually do, in plain English · and how they protect your data on SimplyScan.
By Daniel A · Kraftwire Software
· 6 min readEvery serious security page makes the same two promises: AES-256 encryption at rest and TLS 1.3 in transit. SimplyScan makes them too. But what do those standards actually do · and why should you, as someone shipping a vibe-coded app, care?
This guide explains both in plain English, shows where they protect you (and where they don't), and walks through how SimplyScan applies them to your scan data.
The two states of your data
Data only ever exists in two states, and each needs its own protection:
- At rest · sitting on a disk somewhere: database rows, file storage, backups. The threat is someone getting hold of the physical disk, a stolen backup, or raw storage access.
- In transit · moving over the network between your browser and a server, or between servers. The threat is eavesdropping, interception, and tampering along the way.
Encryption at rest answers the first threat. TLS answers the second. You need both · encrypting a database is pointless if the connection to it is readable, and a perfect connection does not help if the disk behind it is open.
What AES-256 actually is
AES (Advanced Encryption Standard) is a symmetric cipher standardized by the US National Institute of Standards and Technology in FIPS 197. The 256 refers to the key length: 256 bits, which gives 2^256 possible keys.
That number is the entire story of why AES-256 is trusted:
- A brute-force attack would need to try more keys than there are atoms in the observable universe.
- No practical attack against full AES-256 has ever been demonstrated, despite 20+ years of public cryptanalysis.
- It is approved in the US for protecting classified information up to TOP SECRET, and it is the default choice of banks, governments, and every major cloud provider.
When a platform says your data is encrypted at rest with AES-256, it means the database files and backups on disk are ciphertext. Someone who steals the disk gets noise, not your data.
The honest caveat: encryption at rest protects against stolen storage · it does not protect against application-level access. If your app leaks data through a missing RLS policy or an open API endpoint, AES-256 never enters the picture, because the application decrypts data legitimately before serving it. That is exactly the layer SimplyScan scans.
What TLS 1.3 actually is
TLS (Transport Layer Security) is the protocol behind the padlock in your browser. Version 1.3, defined in RFC 8446, is the current standard, finalized in 2018 · and it is a genuine upgrade over 1.2, not a version bump:
- Legacy cryptography removed. Every cipher that enabled the famous downgrade attacks against older TLS (RC4, 3DES, CBC-mode ciphers, RSA key exchange) is simply gone. There is nothing weak left to negotiate down to.
- Forward secrecy is mandatory. Every connection uses ephemeral keys, so even if a server key leaks later, recorded traffic from the past cannot be decrypted.
- Faster handshake. One round-trip instead of two, which is why TLS 1.3 sites also feel snappier on mobile.
- More of the handshake is encrypted. Certificates and extensions are hidden from passive observers.
TLS 1.3 means every byte between your browser and the server · credentials, scan results, payment pages · is protected against both eavesdropping and modification while it travels.
How SimplyScan applies both
Here is the concrete picture for your data on SimplyScan:
- At rest: all data · accounts, scan results, findings · lives in infrastructure that encrypts storage with AES-256. Those providers hold SOC 2 Type 2 and ISO 27001:2022 certifications and are continuously audited (the certifications are held by the infrastructure providers, not by Kraftwire Software directly).
- In transit: every connection to simplyscan.io and our API is TLS 1.3.
- Application layer: encryption alone is not enough, so we also enforce Postgres row-level security · users can only ever read their own scans · and integration tokens (Slack, GitHub, Linear) are stored write-only, meaning they can be used to deliver findings but can never be read back out through the client.
- Repo scans: if you connect a public GitHub repository, source files are fetched, analyzed in memory, and discarded · never stored permanently.
What this means for your own app
If you are shipping a vibe-coded app, apply the same two-layer thinking:
- Serve everything over HTTPS with TLS 1.2 as the minimum and 1.3 preferred · your hosting provider almost certainly supports it, and our SSL/TLS checker verifies your certificate chain and protocol versions in seconds.
- Use a managed database (Supabase, Firebase, RDS) · you get AES-256 at rest for free, which beats anything hand-rolled.
- Remember that neither standard protects your application logic. Missing access controls, leaked API keys, and open endpoints are all invisible to encryption · run a full scan to catch those.
Related free tools