What Is a Security Audit Log?

A security audit log is an append-only record of every significant security event in the system: sign-ins, lockouts, password changes, user and role edits, and every permission that was granted, revoked, or denied. Each entry captures who did what and when, and the application only ever adds to the log, never edits or deletes it. That makes it the durable, tamper-resistant trail an administrator or auditor uses to answer questions about access after the fact.

EDGEBIC by User Solutions writes to this log automatically as people sign in and as administrators change access. This article defines the term and what it records. For the access model that produces many of these events, see how EDGEBIC handles users and roles.

How It Works

Whenever something security-relevant happens, EDGEBIC writes one row to the audit log describing it. The row carries the kind of event, the timestamp, the username as it stood at that moment, and, where relevant, the specific permission code involved and a short free-text detail.

The log is append-only by design. The application never updates or removes an existing row, so the record of what happened cannot be quietly altered later. To keep entries readable even after an account changes, the username is copied onto the row at event time rather than looked up later. Rename or delete the user tomorrow and yesterday's entries still name them correctly.

Writing the log is also deliberately independent of the action that triggered it. If the log write itself were to fail, the sign-in or command it describes still completes, so audit trouble never blocks legitimate work. The trade-off is that log health is worth monitoring in its own right.

A Concrete Example

Think of the log as the visitor sign-in book at a secure plant entrance, except the pen only writes and the pages cannot be torn out. Every arrival, every badge that was refused, every time a guard handed someone a new key: all of it goes in the book, in order, with a name and a time.

In EDGEBIC terms, a single afternoon might record:

Read top to bottom, the story is clear: someone struggled to sign in as Alice and got locked out, an administrator later signed in and widened the Planner role, and Bob tried an action he was not allowed to take. None of these rows can be edited away.

How EDGEBIC Uses It

EDGEBIC records the full range of security events: sign-in success and failure, lockout, logout, password change and reset, user create, update, delete, activate, and deactivate, role create, update, delete, and assign, and permission grant, revoke, and denial. A permission-denied event names the permission and the person, so blocked attempts are as visible as successful ones.

There is currently no viewing screen for the trail in the application. It exists as an append-only record inside the database that an administrator or support can query when a compliance or investigation question genuinely calls for it, which is why a request is best scoped to a date range and a set of event kinds rather than the whole log. The everyday version of most access questions is answered on screen instead, by the Active, Locked, and Last login columns of the Users grid. Because nothing is ever pruned, the trail stands as durable evidence long after the fact: a cluster of failed sign-ins and a lockout is the fingerprint of a password-guessing attempt, and it is still there to be produced months later. Practical routing for both is in how to review the security audit trail.

For the account-protection mechanism behind those lockout rows, see the sibling term account lockout, and for the access model itself see effective permission. More definitions live in the manufacturing glossary.