Definition
Audit Log (audit log) records key operations such as user login, configuration changes, OTA delivery, device deletion, etc., including operator, time, object, result and other information. It is used for security audit, compliance traceability and RCA root cause analysis, and cooperates with RBAC to achieve permission traceability.
Record range and fields
Audit logs usually include: operation subject (user ID, IP, client), operation type (create/modify/delete/delivery), operation object (device, product, firmware, etc.), snapshots or change summaries before and after the operation, timestamp (UTC storage is recommended), operation results (success/failure and reasons). Device Management Platform requires mandatory auditing of sensitive operations such as batch deletion, certificate revocation, OTA full push, etc.
Compliance and Retention
Industries such as finance, healthcare, and energy have clear compliance requirements for audit logs, such as logs must be tamper-proof, retention periods (usually from 6 months to several years), and they must be exportable for regulatory review. The platform can use WORM storage, hash chains, or blockchain evidence to enhance tamper resistance, and support multi-dimensional search and export by time, operator, object type, etc.
Integration with operations analysis
Audit logs combined with RCA root cause analysis can trace configuration changes and batch operations before faults, quickly identifying human errors. When combined with RBAC permission models, it can achieve a complete audit trail of "who did what to which object at what time," meeting security standards such as MLPS (Multi-Level Protection Scheme) and ISO 27001.
Which actions must leave a record that cannot be changed
An audit log does not mean storing every interface flow. It means writing, for actions that change a device’s fate, a record that cannot be rewritten afterward. Successful and failed logins, credential resets, permission changes, bulk deletes, firmware delivery, and restarts or factory resets inside remote control all belong in this class. Each record must be able to answer four questions: who initiated it, from where, which object it acted on, and whether the platform judged it a success or a refusal. The object should be a stable identifier, such as a device identifier and a product identifier, not only the display name at the time, because the name can be changed later.
The condition for using it is that the platform can already tell operators apart, and that critical writes all pass through the same authorization path. An action that bypasses the console, edits the database directly, or is called by a script through an internal interface leaves a hole in the audit if it never enters that path. The log should be written when the action is submitted, not filled in after the business operation succeeds. Failures and refusals must be kept as well, or brute-force attempts and unauthorized calls stay invisible. During retention, records may only be appended. Operators must not be able to change the time or the result. When the log is read together with device credential changes, a secret reset and a certificate revocation must each have their own entry, or there is no way to explain why a device suddenly fails authentication.
Why a later trace cannot be tied to a person
The most common gap is many people sharing one administrator account. The log can only show that account, not the person on shift. Another gap is recording only “delivery succeeded,” without which configuration version was delivered or which set of devices it applied to. The site cannot be reconstructed afterward. If clocks use each server’s local time and have no common source, the order of operations across nodes is reversed, and an investigation will treat a later change as the cause. If an export trims the before-and-after snapshot into the single phrase “modified,” the audit loses its value as a check.
System jobs and human operations must not share one column without naming the initiator. A scheduled sync or an automatic delivery from the rule engine, if shown as some user, will be misread as a human mistake. The reverse, recording a person’s bulk operation as “system,” leaves no one responsible. A query must be able to narrow by object, action type, and time, not only download the whole store. The audit of a downstream command should keep the command kind and the target device, and should not write a secret or a password in clear text into the log body. If the log itself contains a credential in clear text, the audit store becomes a new place to leak it.
When an exported record can actually be checked
If an audit cannot reconstruct, for one object, the actions over a period in order, it is only a pile of text that cannot be checked. Each exported row should carry a time, an action, an object identifier, and a result that the exporter cannot alter, and it should say whether a person or a system job initiated the record. Exporting only successes makes it look as if nobody tried a dangerous operation during that period. Time should come from the platform’s common clock, and the export file should name the time zone. Otherwise, opened in another region, the order will not match the site duty roster. The object should use a stable identifier. A display name may be an extra column, but it cannot replace the identifier, because the name can be changed afterward.
After records are archived inside the retention period, they must still be findable by the original conditions, not searchable only in hot storage while cold storage holds an archive that cannot be queried. To check that an export is complete, compare the record count and the first and last times for that period, not only whether the file opens. If one bulk delete is missing, treat it as an audit gap, not as something to patch from memory with a sentence. The operator should not have permission to delete or rewrite their own records, and the person who approves someone else’s export scope should not be able to rewrite what has already been exported. Otherwise the log can only prove that the system once had this feature. It cannot prove what happened on site.