When people think about a smart door lock, they usually think about convenience.
You walk up to your front door with your hands full of groceries. Instead of reaching for your keys, you tap your smartwatch. A second later, your phone confirms the request, the lock clicks, and the door opens.
It feels simple.
After a few days, it becomes second nature. You can unlock the door for a family member while you're still at work, create temporary access for a guest, or check whether you remembered to lock the door before leaving home.
You don't think about the technology anymore.
You just trust that it works.
What most people never see is everything happening behind that one tap.
Your smartwatch communicates with your phone. Your phone communicates with the manufacturer's mobile app. The app sends a request across the Internet to the manufacturer's cloud, where your identity is verified. That request is then sent back to your home, where the lock decides whether it should trust the command before turning the deadbolt.
All of that happens in just a few seconds.
When you tap "Unlock," you aren't thinking about Bluetooth packets, cloud authentication, or encrypted communication.
You're thinking about getting inside your house.
And that's exactly how it should be.
Good engineering hides complexity so people can focus on solving their problem instead of understanding the technology underneath.
Long before that lock ever reached your front door, teams of engineers spent months making sure every part of that experience worked. Software engineers built the application. Systems engineers designed how the components communicate. Quality engineers verified that everything worked reliably under countless conditions.
They verified that the lock unlocked when you tapped the button, that family members could be invited without confusion, that Bluetooth reconnected after losing signal, that firmware updates completed successfully, and that the product continued to behave predictably even when the Internet wasn't available.
All of those efforts lead to the same goal.
Does the product work the way it was intended?
Then I look at the same lock differently.
I look at it through the lens I've developed over years of working in Product Security. Instead of assuming someone will use the product the way it was intended, I assume someone will eventually try to use it in ways the engineers never expected.
That shift changes almost every question I ask.
| Traditional Testing | Product Security |
|---|---|
| Does the app remember my session? | Can that session be hijacked or replayed? |
| Does the notification show the right message? | Can a fake notification be injected to phish the user? |
| Does the update install correctly? | Can a malicious update be installed instead? |
| Does the API return the right data for me? | Can I request data that belongs to someone else? |
The examples above could apply to almost any connected product.
For this smart lock, they lead me to questions like these.
What assumptions is the smartwatch making?
What assumptions is the phone making?
What assumptions is the mobile app making?
What assumptions is the cloud making?
What assumptions is the lock making?
More importantly...
Can I break those assumptions?
Can I convince the lock that I'm a trusted phone?
Can I replay yesterday's unlock request?
Can I intercept communication between the phone and the cloud?
Can I manipulate the information before it reaches the lock?
Can I exploit one weak assumption to gain access to the entire system?
Every product is built on assumptions. Assumptions about who is using it, how they'll interact with it, what they're allowed to do, and what they should never be able to do.
My job is to identify those assumptions, determine whether they can be broken, and understand what happens if they are.
That mindset is called Product Security.
Finding a weakness isn't the finish line.
It's the beginning of a conversation.
Once we understand where the risk exists, I work alongside software engineers, systems engineers, quality engineers, architects, and other stakeholders to understand why those assumptions failed and what we can do about them.
Depending on what we discover, the solution might be stronger authentication, encrypted communication, validating every request, detecting suspicious behavior, or something entirely different.
More often than not, it's several controls working together.
Security is rarely a single control.
It's layers of controls.
One control may prevent an attack. Another may detect it. A third may limit its impact if the first two fail. Sometimes those controls intentionally overlap because no individual security control is perfect.
The objective isn't to build a product that's impossible to attack.
No engineer can honestly promise that.
The objective is to understand the risks, reduce them as much as practical, and build products people can trust.
Sometimes those risks involve protecting personal information.
Sometimes they're about preventing unauthorized access.
In industries like medical devices, they can also help reduce risks that ultimately affect the safety of the person using the product.
That's the lens of Product Security.
What surprised me over the years is that I didn't stop looking at products this way when I left work.
Whether I'm setting up a smart lock, flying an airplane, experimenting with AI, repairing my garage door, or learning a new piece of technology, I find myself asking the same questions.
How does this actually work?
What assumptions are being made?
What happens if those assumptions are wrong?
What's happening beneath the surface that most people never see?
That's the lens I bring to everything I write on ProdSecPilot.
Not because every story is about cybersecurity.
But because every story starts with curiosity.
My hope is that the next time you use a product you rely on every day, you pause for just a moment and wonder what's happening beneath the surface.
Maybe it's your phone.
Maybe it's your car.
Maybe it's your smartwatch.
Or maybe it's the smart lock on your front door.
The goal isn't to become a Product Security Engineer.
It's simply to become more curious.
The next time you tap "Unlock" on your phone, you'll probably still be thinking about getting inside your house.
But maybe, just maybe, you'll spend a second wondering about everything that had to happen before that door clicked open.
That's where curiosity begins.
And that's the lens through which I explore the world.
If this article resonated with you, here are a few places to continue.
→ About
→ Home