Every article in this series dealt with deciding what should happen. Sign-in records are the other half, because they are what your system wrote down while it happened.
They are on for every account, with nothing to switch on. So the useful question is not whether you have them. It is whether you know what is in them before the day that matters.
What do sign-in records actually hold?
Every sign-in attempt, successful or not. Each entry records the person and the username exactly as somebody typed it. It also records the date and time, whether it succeeded or failed and why, the source address, the device, the sign-in method and the type of event.
Read that list again and notice what it is. It is not a description of how your account is configured today. It is a set of facts about moments that have already passed, which is a different thing to have.
Why does the sign-in method matter?
Because the record does not only say that a sign-in happened. The method is one of the fields, so an entry recorded against an authenticator app is distinguishable from one recorded against a password alone.
Enrolment and re-authentication events are recorded in the same log. So if you require a second factor, the record that people enrolled sits alongside the sign-ins themselves rather than somewhere separate. Our piece on making enrolment mandatory covers that rollout, and our piece on trusted devices covers why the method column is worth looking at.
What do sign-in records not cover?
Authentication, and only authentication. Sign-in records answer who arrived, when, from where, and which method the account recorded for that sign-in. That is the whole of their scope, and it is worth saying so plainly rather than letting somebody assume more.
Being precise about that is worth the effort, because the vocabulary around records runs together in a meeting. We set out the wider case for keeping records in our piece on audit trails as an operational requirement.
One wrinkle to expect. Older entries pre-date the device and method columns, so those appear blank on historical entries. Better to know that now than to discover it while somebody is waiting.
What should you do with them before you need them?
Three things, and the point of doing them while nothing is urgent is that you learn what your own records look like with no pressure attached.
- Read the failed attempts as well as the successful ones. Both are captured, each with its reason, so the failures are already there to read.
- Take a single entry and read every field on it. That shows you exactly what one event produces, rather than what you assume it produces.
- Write down where this lives, so more than one person on your team knows.
The recordkeeping rules for financial firms and FDA guidance on data integrity are both worth reading alongside this. Neither is a Kohezion document, and neither says anything about us, which is rather the point of reading them.
Retrieval or reconstruction
That is the distinction worth holding on to. Retrieval is looking something up in a record that already holds it. Reconstruction is working the answer out from memory and inference while people wait.
Nothing about the record changes which of those you are doing. What changes it is whether you have read it before. Somebody who has read the record once already knows what it can answer and what it cannot.
The method changes, the question does not
That is the note to close the series on. Across eight articles we covered who should see what, and how to check it still holds. We covered which second factor fits your people, what to do about shared accounts, and how to require enrolment. Then how long a device should stay trusted, and what passkey sign-in offers on Enterprise accounts.
All of those decide what can happen. This one is about showing what did. And whichever method your people end up using, the question stays the same. Who signed in, when, and how do you know.
Our guide to user permissions holds the wider model behind all of it. The habit of checking them sits in our piece on running a user access review. To walk through what your own records would produce, talk to an expert.
