Lakshya

Identity & Access · Chapter 1

Authentication, authorisation, audit

Three different questions. Conflating them is the root of most identity incidents.

Identity work has an unusually bad acronym problem, and it hides a simple structure. Almost everything in this field is one of three questions, and the discipline gets much easier once you can place any control into the right one.

THREE DIFFERENT QUESTIONS, ROUTINELY TREATED AS ONE AUTHENTICATION Who are you? “prove it” password, passkey, MFA, certificate, biometric AUTHORISATION What may you do? “and to what” roles, groups, policies, entitlements, scopes AUDIT What did you do? “and when” logs, access reviews, segregation of duties Most identity incidents are authorisation failures reported as authentication failures. Nobody broke the login. Someone who legitimately logged in could reach more than they should have — usually because a leaver kept access, or a mover accumulated it. That is chapter 3.
Authentication proves identity, authorisation grants power, audit records use. They are different systems, usually owned by different teams, and failing at one tells you nothing about the others. Strong MFA on an account with excessive entitlements is a well-locked door to a room that should not exist.

Why the distinction pays off immediately

When an incident happens, the first useful question is which of the three failed. Almost every reported “account compromise” is really two failures: authentication let someone in, and authorisation let them reach far more than that account should have touched. The second failure is what turned an incident into a breach, and it is nearly always the cheaper one to have prevented.

  • Authentication is largely a solved problem if you deploy phishing-resistant factors. Passkeys and FIDO2 hardware keys defeat the credential phishing that causes most intrusions, because the credential is bound to the origin and cannot be replayed elsewhere.
  • Authorisation is where the hard, unglamorous work is — and where most organisations are weakest, because it requires knowing what every person should be able to reach, which nobody has ever fully written down.
  • Audit is what makes the other two provable. Without it you have opinions about your access posture rather than evidence.

The question that reframes an identity programme

Not “how do we stop attackers logging in?” but “when an attacker does log in as an ordinary employee, what can they reach?”

The first question has diminishing returns and a well-understood answer. The second is where the actual risk lives, and it is a question about authorisation, not authentication.

← All chaptersFederation, SSO, SAML and OIDC →