A few years ago, I watched a security team celebrate a successful rollout of multi-factor authentication. There were cupcakes. Someone made a slide with a green checkmark. And about six weeks later, an attacker walked straight through the same environment using a stolen session token, never touching the MFA prompt at all. Nobody had done anything wrong, exactly. They had solved the problem they were handed: make logging in safer. The trouble is that logging in is a single moment, and a working day is thousands of them. That gap is where the idea of continuous authorization comes from. It is also where the headaches begin.
The Old Deal: Prove Yourself Once
Traditional access control runs on a simple bargain. You show up, you prove who you are, and the system hands you a pass. After that, you move around more or less freely until the pass expires or you log out.
It is the digital equivalent of a badge swipe at the office front door. Once you are inside, nobody asks again whether you should be in the finance wing or whether it is strange that you are copying the entire customer database at 3 a.m.
This worked tolerably well when everything lived inside one network and “inside” meant something. But our systems stopped looking like a castle a long time ago. Now we have cloud apps, contractors on personal laptops, APIs talking to other APIs, and employees working from airports, cafes and kitchen tables. The castle walls are gone. The pass, though, is still treated like it means the same thing it always did.
What Continuous Authorization Actually Means
The idea is to stop treating access as a one-time decision. Instead, the system keeps asking, quietly and constantly: should this person, on this device, in this situation, still be allowed to do this thing right now?
Notice the shape of that question. It is not just about identity. It is about context, and context changes mid-session.
The user’s device falls out of compliance because a security agent stopped running.
Their location jumps from one place to another in ten minutes.
Their behaviour shifts: a person who normally reads three documents a day suddenly downloads three thousand.
A threat feed flags the IP address they are connecting from.
Their role changes, or their employment ends, while they are still logged in.
In a continuous model, any of these can tighten, step up or revoke access on the spot, without waiting for the next login. It is the philosophy behind zero trust, taken seriously: never trust, always verify and keep verifying.
On paper, it is hard to argue with. In practice, it gets complicated fast.
Conundrum One: Security Versus the People Being Secured
Here is the first tension, and it is a very human one. Every additional check is a potential interruption. If a system re-evaluates trust every few seconds and responds to every wobble with a challenge, people will hate it. They will be pulled out of a flow state to re-verify for the first time before lunch.
And humans, being clever and impatient, find workarounds. They share accounts; they keep sessions open on shared machines. They save passwords in a text file called “passwords.txt” and feel mildly guilty about it.
Security that people route around is not security. It is theater with extra steps.
The real craft then is making continuous authorization invisible when things are fine and loud only when they are not. A good system does most of its thinking in the background. You only notice it when something genuinely changes. Getting that balance right is less an engineering problem than a design and empathy problem, which is a strange thing to say about access control, but there it is.
Conundrum Two: The Signals are Messy
Continuous authorization depends on signals: device health, location, behaviour, network reputation, time of day. In a slide deck, these are crisp and reliable. In the real world, they are noisy.
People travel. They get new phones. They work odd hours because a deadline is looming or because they have a toddler who does not believe in sleep. A VPN can make a perfectly honest employee look like they are in another country. Behavioural baselines are built on assumptions about what “normal” looks like, and normal is a slippery thing, especially for the people whose jobs are the least routine.
So you get false positives. A senior engineer gets locked out in the middle of an incident response because their behaviour looked unusual. Of course it looked unusual; there was an incident.
It works the other way too. A careful attacker who mimics ordinary behaviour, moving slowly and staying inside normal patterns, may glide right under the thresholds. Any system that scores risk will eventually be gamed by someone patient enough to study the score.
The uncomfortable lesson is that more signals do not automatically mean more certainty. Sometimes they just mean more things to argue about.
Conundrum Three: The Cost of Always Watching
There is a practical side too, and it is not glamorous. Evaluating access continuously means your policy engine is on the critical path of nearly every action. If it is slow, everything is slow. If it goes down, you have to decide, ahead of time, whether the whole company freezes (fail closed) or whether everyone is let through unchecked (fail open).
Neither answer feels good. Fail closed and an outage in your authorization service becomes an outage in everything. Fail open, and you have built a security system with a convenient off switch, which attackers will happily look for. Then there is the plumbing: different apps speak different dialects. Some modern platforms support standards for sharing security events in near real time, so one system can tell another, “this session is no longer trustworthy.” Plenty of older software supports nothing of the kind. It was built to check a pass at the door and then look away. Retrofitting continuous checks onto systems like that can mean heavy rework, awkward proxies or simply accepting that some corners of the estate will stay in the old world for years.
Conundrum Four: Who Gets to be Watched and How Closely?
This is the one that does not get enough airtime. Continuous authorization, especially the behavioural kind, is a form of ongoing observation. It looks at how you type, what you access, when you work, and where you are. Most of the time, that is justified and proportionate. But there is a line and it is easy to drift across it without noticing.
A system built to detect compromised accounts can quietly become a system that tracks productivity, monitors personal habits, or builds a detailed profile of someone’s day. Employees notice. When people feel watched rather than protected, trust erodes and trust is the thing you were trying to protect in the first place.
There are decent answers here: collect only what you need, be open about what is being measured and why, set sensible retention limits and keep humans accountable for decisions that affect people’s ability to do their jobs. Privacy laws in many places push in the same direction. But these are choices an organization has to make deliberately. Technology will not make them for you.
Conundrum Five: What do You do When the Answer is “Maybe”?
Traditional access is binary. Allowed or denied. Continuous authorization lives in the gray zone, where the honest answer to “should this person have access?” is often “probably, but I am not sure.”
The mature approach is to respond proportionally rather than all-or-nothing. A slightly odd signal might trigger a quiet re-check of the user’s device. A more suspicious one might ask for a fresh authentication. A serious one might limit the session to read-only or cut off access to the most sensitive data while leaving everything else alone. Think of a dimmer switch rather than a light switch.
That sounds elegant, and it is, but it forces hard conversations. Someone has to decide what “sensitive” means. Someone has to decide how much risk a given action can tolerate. A request to view a lunch menu and a request to wire money should not be judged by the same standard, yet organizations often struggle to even agree on which data matters most.
So Where Does This Leave Us?
If this all sounds like an argument against continuous authorization, it is not. The old model is genuinely broken and the stolen-token story I opened with is not an exotic scenario. It is Tuesday. Session hijacking, token theft and compromised devices are exactly the failures a one-time check cannot see.
But I think the honest framing is that continuous authorization is not a product you buy. It is a posture you grow into. A few things seem to help:
Start with what matters most. You do not need to continuously evaluate every click. Begin with your crown jewels, such as admin consoles, financial systems and sensitive customer data, and expand from there.
Prefer graduated responses. Build the dimmer switch before you build the kill switch. Step-up checks and reduced privileges give you room to be wrong without wrecking someone’s afternoon.
Measure the friction. Track how often legitimate people get challenged or blocked. If that number is climbing, your system is training users to resent it.
Be transparent. Tell people what is being observed and why. Surprise is the enemy of trust.
Plan for failure. Decide in advance what happens when the policy engine hiccups, and test it before it matters.