Identity and Access Management: Authentication

Identity and access management, and authentication. Access control is the heart of Domain five, and it begins with reliably knowing, and proving, who someone is.

The scene. The finance team logs into the reconciliation system with a single shared account, finance-one, because it is convenient. Its password is strong and changed regularly, so the team considers access well controlled. Then a fraudulent transaction is traced back to that account, and there is no way to tell which of the eight people who use it was responsible. The password was never the weak point.

The identity model has four parts, and the exam expects you to keep them straight. Identification: the user claims an identity, entering a username. Authentication: the user proves that claim, with a password, token, or biometric. Authorisation: the system determines what that authenticated user is permitted to do. And accountability: the user’s actions are logged and attributable to them.

The most common slip is confusing authentication, proving who you are, with authorisation, what you are allowed to do. Proving identity comes first; granting permissions comes after. The exam swaps these constantly, so read which one the question is describing.

Authentication draws on three categories of factor. Something you know: a password, a P-I-N. Something you have: a hardware token, a phone receiving a one-time code. And something you are: a biometric, a fingerprint or a face. Multi-factor authentication means combining two or more different categories.

So what counts. A password plus a one-time code from a token is genuine M-F-A: something you know plus something you have.

But two passwords are both something you know, a single factor used twice, not multi-factor.

And a password plus a security question is still two knowledge factors; two biometrics are two of something-you-are. Same category twice is still single-factor, however many steps it takes.

So the rule is: two different categories. When a question asks which option is true M-F-A, look for two different kinds of factor, not the same kind twice. That is the trap, set over and over.

Now back to the shared account, because that is the real finding. The finance team’s strong password was never the issue. Their shared account is, because it collapses accountability: when eight people use one login, no action can be traced to an individual, so the fraudulent transaction cannot be pinned to anyone. A strong password protects against outsiders guessing it; it does nothing about telling your own people apart.

Accountability depends on unique identities, one account per person, so that every action is attributable. This is why shared and generic accounts are a standard finding, and why a shared privileged account, like a common admin login, is worse still.

So carry this away. It is only multi-factor if the factors come from different categories, know, have, are; two of the same kind is single-factor dressed up. And a shared account breaks the accountability the entire identity model exists to provide, and a strong password does not fix it, because the weakness is attribution, not secrecy.