Access Denied: Device-Bound Authentication is the only Authentication

What If Everything You Know About Credential Security Is Wrong?

Have you noticed how every major data breach post-mortem seems to follow the same script? "If only users hadn't reused passwords..." or "MFA could have prevented this..." Sound familiar?

But here's a question worth pondering: Why do we keep blaming users when our systems fundamentally trust unverified access attempts?

I call this the Convenience Narrative

Let's be honest - how many times have you heard vendors or security teams blame phishing, credential stuffing, or weak passwords for breaches? It's become such a common refrain that we barely question it anymore.

But ask yourself: When was the last time you actually verified the assumption that data access attempts in your application was properly authenticated?

According to OWASP Top 10, broken access control has maintained its #1 position for over a decade.

Think about that for a moment.

If this was truly about user behaviour, wouldn't we see different categories top that list?

Want an Uncomfortable Truth?

Here's what the standards bodies and security frameworks aren't shouting about (but should be): Your application's blind trust in sessions is the real vulnerability.

Don't believe me? The NIST Special Publication 800-63B explicitly states that session management and access control cannot be delegated to third parties. Why? Because only YOU know your application's authorisation requirements.

Ask yourself: Are you relying solely on session tokens without additional context for any period of time? What happens when the token is presented by someone other than who authenticated? Are they granted access? Go check, login, grab the token, use it manually on another device to simulate the bad actor and see what your software does.

The Device Trust Problem

Let's get technical for a moment.

The question we need to answer is: What happens when a user's session token is used from a completely new device? If you're like most developers, probably nothing. But why?

The FIDO Alliance and W3C WebAuthn specifications provide robust frameworks for device-bound authentication. Yet how many of us actually implement device attestation in our session verification mechanism?

Would you let a stranger into your house just because they had a copy of your key? Then why do we let unrecognised devices access our systems just because they have a valid session token?

Here's what NIST SP 800-63C suggests about federation and session management - it's not about choosing OAuth or OIDC, it's about implementing them correctly with proper access controls. My 2 cents? If you're building an OIDC implementation, don't just implement the endpoints with bare minimum functionality to integrate with the other party - use a OIDC library, or SDK, just don't roll your own bespoke OIDC without actually looking at the many RFC documents and getting formal verification you've implemented it to spec properly. Doing it bespoke not only tells the world you think you're smarter than the rest of the world, in your own silo, the systems security properties are unknown - assumptions about your security controls are the most dangerous risks you can have in an organisation. A blind spot with a false sense of security that's glaringly obvious to bad actors.

How to know if you're at risk?

Start asking these questions in your next architecture design or code review:

1. How are we verifying the authenticity of each data change/access/delete attempt?
2. What device attestation are we implementing to verify the user is trustworthy, and authorised for these interactions?
3. How are we handling step-up authentication when we encounter low trust situations, or when an elevated permission is required, or when a user device or location is a potential risk?
4. Are our sessions bound to specific devices, or able to allow users to approve/deny seen devices?

Rather than implementing yet another MFA solution, consider this approach (because like we already established, you can't buy this solution or find it in third party code):

1. Device Registration: Distinct from one-time user registration. Every new device must be explicitly approved through a phishing-resistant authentication mechanism. The WebAuthn standard provides an excellent framework for this on the browser side, native apps have their own flavours too.

2. Continuous Verification: Remember what Zero Trust architecture teaches us - verify every access attempt, not just the initial authentication. You can check a lot of risks without needing to prompt the user with step-up MFA, with numerous outcomes, for any context - it's rare that new application security contexts are invented, since the ‘container’ there's not been any..

3. Step-Up Authentication: Segue, sensitive operations should always require fresh authentication. As the FIDO2 specifications suggest, this should be phishing-resistant and preferably biometric or hardware-key based. When is step-up MFA required? You're the only one that can answer that about your app and the answer is rarely, extremely rarely, never. Everyone has many step-up MFA needs because everyone uses trusted sessions (only apps without sessions can genuinely say they don't need step-up MFA).

4. Session Binding: The linchpin, tie sessions to registered devices using cryptographic attestation. The W3C Device Posture specifications provide guidance on implementing this securely.

What will you do now you know?

Isn't it time we stopped blaming users for what are fundamentally architectural failures in our systems?

Remember Authentication and authorisation are YOUR responsibility as a software maker. No amount of user training or password policies can fix broken access controls. Only sticky tape solutions like a password manager can be tried to make your/our failures stop hurting users - the user see's this as lipstick on a pig.

We, users who are blamed, are tired of being told it's our fault we are getting our identities stolen, our finances and time impacted, and stress levels using the internet services meant to make our lives simpler… enough is enough.

After all, as the OWASP ASVS reminds us - security isn't about checking boxes, it's about protecting our users' data through proper system design.

What steps will you take today to move beyond the "blame the user" mindset and implement proper access controls in your systems?

What's your next move?