Security used to be something teams talked about when they had time.
Now it’s part of the product. Not because people suddenly became security experts, but because everyone has been burned at least once. A password leak. A fake login page. A “your account was accessed from a new device” email at 2 a.m.
If you build apps, you already know the awkward truth: users don’t read your security blog post. They judge you by the friction and the failure modes. This is the new baseline. It’s mostly discipline in the unglamorous parts of the product.
This article isn’t legal advice, and “perfect security” isn’t a real thing.
The goal is simple: reduce avoidable risk, keep users safe, and avoid trust-killing mistakes.
The baseline has changed
Ten years ago, lots of apps got away with weak passwords, password reset links that barely worked, and permission requests that felt like a ransom note. A lot of “security” was really just hoping nobody tried.
Today, users expect more by default. They want sign-in that’s fast without forcing them to invent a password they’ll forget, recovery that still works when they’ve lost access to an old phone, and clear warnings when something suspicious happens. And they don’t want you grabbing contacts, location, or microphone unless there’s a real reason.
And if your app fails at those moments, it doesn’t matter how good the rest of your UI is.
The practical security baseline (the stuff users actually notice)
Most security wins show up in the boring moments: sign-in, recovery, permissions, and what happens when something looks off. If login is painful, users reuse passwords, pick weak ones, or bail. So start with an auth that respects reality: offer passkeys with Face ID, Touch ID, or device PIN where it fits, keep passwords for the holdouts, and make it work across devices. Then fix sessions: expire them on a schedule, let users see active devices and sign out, and re-authenticate for sensitive changes like email, payout, or security settings.
Recovery is where trust is won or lost. Treat it like a front door, not a spare key under the mat. Avoid SMS-only recovery if you can, because SIM swaps, number recycling, and lost phones are normal. Give multiple recovery options (email plus passkey, authenticator, or backup codes), throttle attempts, and step up verification for high-risk changes. Also, explain delays and timelines in plain language so users are not guessing.
Permissions should be earned. Ask for the minimum, when the user triggers the feature: camera on “Scan QR code,” location on “Nearby store finder,” and approximate if that’s enough. Right before the OS prompt, tell them what you need, what you’ll do with it, and what happens if they say no.
Data security is mostly data discipline. Collect less, keep it for less time, and reduce your blast radius with sane retention limits. Encrypt in transit, encrypt sensitive data at rest, keep secrets out of the client, and treat logs as sensitive. When something goes wrong, be specific: log key account events (logins, new devices, security setting changes, email or phone changes, billing or payout updates) without logging passwords or full tokens, and notify users with clear details plus a one-tap path to secure the account.
Finally, be honest about third-party SDKs. Inventory what you ship and what it touches, remove what you don’t use, and re-check data collection after major updates so your disclosures match reality. If you’re rebuilding foundations around auth, sessions, and device management, involve experienced mobile app developers early, because security lives across the app, backend, and identity layer.
Sanity check: modern auth plus sane sessions, recovery that works in real life, permissions that are earned, data you actually need for as long as you need it, specific alerts when something looks off, and a hard look at every SDK you ship.
Trust is built in the boring parts
The apps people trust aren’t the ones with the most security talk. They’re the ones that make login and recovery painless, ask for permissions like they mean it, and speak up when something looks off. Treat security as “later,” and users will leave before you get a second chance.