Identity and access: why IAM is the real perimeter

When work leaves the office, applications live in the cloud and devices belong to anyone, the old idea of a perimeter — a trusted inside and a hostile outside — stops making sense. What remains as the boundary is identity: who you are, what you can do and under which conditions. IAM is not one security component among others; it is the point where most attacks pass through or stop.

Attackers understood this long ago. More and more intrusions break nothing: they use valid credentials, obtained through phishing, password reuse or token theft. In a world like that, the strength of identity is the strength of the defence.

MFA, but the right kind

Multi-factor authentication remains the single control with the best ratio of cost to risk reduction. But not all factors are equal: SMS codes and simple push prompts can be defeated by SIM swaps, real-time phishing or approval fatigue. Where possible, the goal is phishing-resistant methods — hardware keys or passkeys based on standards such as FIDO2 — bound to the service’s domain, so a fake page cannot reuse the authentication.

Coverage matters just as much: MFA holds only as long as there are no shortcuts. An old protocol that does not support it, a “temporary” exception, a weak recovery path — any of these is enough to undo it.

Privileges: how many are actually needed

Most accounts hold more permissions than they use. The gap between granted and needed privilege is exactly what an attacker exploits after the first access. Closing that gap — least privilege enforced consistently — limits how far a compromised credential can travel.

For administrative access, the step change is just-in-time privilege: no standing elevated rights, but elevation requested and granted for the task, with approval and logging, then withdrawn. The fewer permanent privileges exist, the fewer high-value targets are lying around.

The lifecycle: from joining to leaving

Access should be managed as a cycle, not granted and forgotten. On joining, rights consistent with the role. On role change, revocation of what is no longer needed — this is where privilege creep is born, when you add without ever removing. On leaving, prompt deactivation of every access, human and non-human.

The weakest point is almost always offboarding: accounts of former staff or vendors that stay active for months are an open door with no keeper. A governed lifecycle, with periodic access reviews (who has what, and is it still needed?), keeps permissions aligned with reality rather than history.

Service accounts, the forgotten corner

Non-human identities — service accounts, API keys, application and automation identities — now often far outnumber human ones, and get far less attention. They do not do MFA, they frequently hold broad privileges, static credentials nobody rotates and no “leaving” moment to trigger deactivation.

They deserve the same discipline: a clear owner, least privilege, short-lived credentials or regular rotation, and an inventory that says what exists and why. An over-privileged, forgotten service account is among the quietest paths to broad damage.

Centralise to control

Every application with its own credential store is one more surface to defend and one more blind spot. Consolidating authentication onto a single identity provider, with single sign-on and federation, is not just convenience for the people using the systems: it is control. One place to enforce MFA, apply policy, disable an access and see what happens is worth more than ten scattered configurations, each ageing in its own way.

Centralisation also cuts passwords: fewer separate credentials means fewer things to steal, reuse or leave active. The flip side is that the provider becomes a prime target — all the more reason to protect it with the strongest controls you have.

Detecting identity attacks

If attacks come through credentials, the defence must read the signals of identity: access from anomalous locations or devices, impossible travel, bursts of failed attempts, repeated MFA prompts that smell of induced fatigue, the sudden creation of new credentials or rules. You do not need to detect everything; you need the few signals that almost always precede abuse.

These events should be logged, retained and — where possible — wired to a response: block, re-challenge, alert. IAM without detection is a lock where you never know whether someone has tried the key.

The takeaway

If identity is the perimeter, IAM is the load-bearing wall. Phishing-resistant MFA with no shortcuts, privileges cut to what is needed and elevated only when required, a lifecycle that revokes with the same care it grants, service accounts governed like people, and detection that reads the signals of abuse: much of modern security is won or lost right here.