Identity & Access Management

The instinct after an incident is to make passwords harder - longer minimums, more complexity, faster rotation. It rarely helps, because the failure is structural rather than a matter of strength. A password is a shared secret: your user knows it, and so does every system that verifies it. It travels. It gets typed into things. It can be copied without leaving a trace, and a copy is functionally identical to the original.

That is why phishing works on people who know better. A convincing sign-in page does not need to break anything; it only needs the user to hand over a string, which is exactly what the system trained them to do many times a day. And once an attacker has that string, every control downstream sees a legitimate user doing legitimate things.

Multi-factor authentication was the industry's answer, and it genuinely closed the easiest attack. But push-based and code-based MFA are still shared secrets with a second step attached. Adversary-in-the-middle toolkits proxy the whole exchange, including the code. MFA fatigue attacks simply ask the user thirty times at 2am until somebody taps approve. The gap is not that MFA is weak; it is that anything replayable eventually gets replayed.

Phishing-resistant authentication - passkeys, FIDO2 security keys, Windows Hello for Business, certificate-based auth - changes the shape of the problem. The private key is generated on the device and never leaves it. The browser will only release an assertion to the exact origin the key was registered against, so a lookalike domain gets nothing. There is no code to read out, no prompt to fatigue, and nothing an intercepting proxy can usefully forward.

Ask most organisations who holds administrative rights and you get a confident answer. Ask who held them at 3am last Tuesday, for how long, and under what approval, and the answer becomes a spreadsheet exercise. That gap is standing privilege - access granted once, for a good reason, and never given an end date.

It accumulates through entirely sensible decisions. An engineer needs elevated rights to fix a production issue at midnight, so they are added to a group. The issue is fixed. Nobody removes them, because removing access is a change with risk attached and no obvious owner. Multiply that by five years of incidents, restructures, contractor engagements, and departures handled by whoever was available that day.

The result is an environment where the blast radius of a single compromised account is far larger than anyone intends. It is also why access reviews are so painful when an auditor finally forces one: the reviewer is asked to approve entitlements whose original justification is long gone, so they approve everything, and the review certifies the problem rather than fixing it.

Just-in-time elevation inverts the default. Nobody holds privilege at rest. When work requires it, the user requests elevation, gives a reason, optionally routes through approval, and receives the rights for a bounded window - after which they expire automatically. The audit trail is a by-product rather than a reconstruction, and the answer to who had admin at 3am becomes a query rather than an investigation.

The technical controls are the easy half. The half that determines whether any of it holds is the lifecycle: what happens when someone joins, changes role, or leaves. Almost every environment we assess handles joining well - there is commercial pressure to get people productive - and handles moving and leaving badly, because neither has an impatient stakeholder.

Moving is the worst of the three. Someone transfers from finance to operations and receives the new access they need. The old access is rarely removed, because removing it requires someone to know what they had and to be confident it is safe to take away. After two or three moves, an individual holds a combination of entitlements that no policy would ever have granted deliberately, and which frequently breaks separation of duties outright.

Leaving is where the delay is most visible. Accounts commonly stay live for days or weeks after a departure - longer for contractors, who often have no HR record triggering anything at all. Every one of those is a credential outside your control with access still inside it.

Fixing this is less about identity tooling than about data. Provisioning driven from an authoritative HR source works; provisioning driven from tickets does not, because tickets depend on someone remembering. In practice the critical path on most lifecycle projects is cleaning up the HR data - accurate start and end dates, correct manager relationships, contractors represented at all - and we would rather tell you that at the start than discover it at month four.

The fear that stops most Conditional Access rollouts is a rational one: a badly scoped policy can lock every user out of everything in about ninety seconds, including the administrators who would fix it. We have inherited environments where a previous attempt did exactly that, and the organisational memory of it delayed the programme by two years.

The way through is measurement before enforcement. Every policy goes out in report-only mode first, which evaluates it against real sign-ins and records what would have happened without affecting anyone. After a week or two of genuine traffic - including the month-end finance crunch, the field staff on hotel wifi, the executive travelling - you have evidence rather than a prediction.

That evidence almost always surfaces the same categories of surprise: service accounts authenticating from unexpected places, a legacy application that cannot do modern authentication, shared devices in a warehouse or clinical setting that do not fit a per-user model. Each needs a decision, and it is far cheaper to make those decisions from a report than from a queue of locked-out users.

Break-glass accounts are non-negotiable. Two of them, excluded from every policy, with long random credentials held in physical custody, monitored so that any sign-in raises an immediate alert. They are the reason a misconfiguration is an inconvenience rather than a crisis, and the reason we can move faster on everything else.