At 03:10 the on-call phone rings. A client’s account manager has had an automated notice that a domain admin credential on their domain controller was used at 01:52. Nobody on the roster remembers doing it. By 08:00 the client wants three answers: who, from where, and whether they were allowed. Here is that morning told twice. First with the four audit logs most stacks have, then with the one trail Guardian Plus keeps. Same incident, same technician, same clock.
It looks like a spreadsheet with four tabs. The identity provider has a sign-in log. The RMM has a remote-session log. The service desk has ticket history. The documentation tool has a credential-reveal log. Each is in its own format, keyed on its own idea of a user, and each has its own opinion about time. The first hour goes on lining them up.
The sign-in log says an account authenticated at 01:51 from an internal address. The RMM says a session opened to dc-01 at 01:54 under a display name that does not quite match the sign-in log’s username. The vault says the domain admin credential was revealed at 01:53 to a user with a third identifier. The desk has a note added to a ticket at 01:55, by someone. Four events, four spellings of one person, correlated by timestamp and by hoping the clocks agree. The reconstruction ends with a plausible story and a gap: the vault says the credential was revealed, but nothing says what happened to the plaintext after that. The technician could have pasted it into a session, or into a chat, or nowhere. The logs cannot tell you.
It looks like one list, in order, with the same identity on every line. This is what the account manager is shown at 03:20.
Every line names the same person because there is one user record. The times are in order because there is one clock. And the credential line says something the four-log version could not: the password was used, not revealed. It was injected into the session server-side, the technician never saw it, and the permission that allowed it is written on the line. That is the difference between an hour of correlation and a page you can read to the client.
Why they were allowed to. Every credential event records who, when, from where and which permission allowed it, including whether it came from an administrator override. The reveal is recorded separately from the use, so “did anyone actually know this password?” has an answer. In the four-log version the closest you get is “the vault says they clicked reveal”, which is where the client’s next question starts rather than ends.
There is a second question of the same kind, from the monitoring side: why did this not page anyone? When a notification is withheld, the reason is recorded. A flap that was damped, a recovery burst that was held back, a quiet-hours rule that swallowed a warning: each is an event with a reason, in the same trail. The alerting side of that story.
Every sign-in, permanently. The authentication log cannot be edited or deleted, by anyone, through any interface.
Every ticket change. Service desk history is append-only, enforced by the database itself rather than by application code that could be bypassed.
Every credential reveal. Who, when, from where, and which permission allowed it, with administrator overrides labelled as such.
Every remote session. Operator, host, mode, start and stop.
Every suppressed alert. With its reason.
Every refused attempt on a private vault. A person’s private vault cannot be opened by any administrator, including a super admin, and the attempt is recorded as its own event.
In our telling, the best part of an hour of correlation before anyone can say what happened, on a night when that hour is between 03:10 and 04:10. Once a quarter that is annoying. On the night a regulator or a client’s lawyer is asking, it is the difference between an answer and a plausible story. And the gap at the end, what happened to the plaintext, is not a cost you can pay down with more effort. The four logs do not contain the answer.
Append-only means no interface can alter or delete what is written. For sign-ins and for service desk history that is enforced by the database rather than by application code, so there is no admin page that could undo it and no bug in our code that could rewrite it. What it does not mean is tamper-proof. The trail is not hash-chained. An operator with database access and the will to do so is a different threat, and we will not call the trail immutable in a room full of auditors. We would rather you knew that here than discovered it in a questionnaire. The same honesty about encryption.
Access control and the audit trail, said plainly, including the two things it is not.