A security incident investigation is three days in. A privileged user accessed a production database server on a Tuesday afternoon. Something changed on that server that caused a downstream service failure two days later.
The authentication log shows the login event. Username, timestamp, source IP, session duration. 23 minutes. The session ended cleanly. Nothing else is in the record.
The investigation needs to know what SQL queries were run. Which tables were accessed. Whether any schema changes were made. Whether any data was exported. None of that is in the log. The record proves the user was there. It cannot prove what they did while they were there.
The scope of the incident cannot be determined. The remediation cannot be confirmed as complete. The finding goes into the report as inconclusive.
This is not an unusual outcome. It is the default outcome in environments where privileged session governance means authentication logging without SMART Audit Trails. And it is increasingly a compliance gap as well as an operational one.
Authentication logs record the events at the boundary of a session: the login event with actor identity, timestamp, source IP, MFA method used, and authentication outcome. The session termination event with timestamp and duration. In some implementations, the target system and protocol.
What authentication logs do not capture: commands executed during an SSH session, SQL queries run during a database session, files accessed or modified, configuration changes made, RDP screen activity, Kubernetes kubectl commands. All of this happens inside the session, after the authentication event.
The distinction matters because authentication logs and SMART Audit Trails are used for different purposes. Authentication logs are useful for access certification, anomalous authentication pattern detection, and confirming that access occurred. They feed directly into the MFA failure and login metrics APIs discussed in previous blogs in this series.
SMART Audit Trails are useful for post-incident investigation, compliance evidence production, and insider threat detection. They answer a different question: not whether access occurred, but what happened during the access.
Control A.8.15 requires that event logs recording user activities, exceptions, faults, and information security events are produced, stored, protected, and analysed. The specific language is user activities. A login event is not a user activity. The commands the user ran during the session, the queries they executed, the files they accessed: those are user activities. A.8.15 requires the latter. An authentication log satisfies the access record requirement at the session boundary. It does not satisfy the activity record requirement for what occurred inside the session. SMART Audit Trails satisfy this second requirement.
The 2022 revision of the standard also strengthened the protection requirement for event logs. Control A.8.15 specifies that log facilities and log information shall be protected against tampering and unauthorised access. For SMART Audit Trail recordings, this means they must be stored in a location the privileged user who ran the session cannot access or modify, regardless of their privilege level on the target system.
SOC 2 CC7.2 requires that the organisation monitors system components and the operation of those controls for anomalous behaviour. Monitoring for anomalous behaviour in a privileged session requires SMART Audit Trail recordings. A login timestamp does not tell you whether the session contained anomalous commands.
The evidence standard for CC7.2 in a SOC 2 audit increasingly includes demonstrating that session-level monitoring is in place for privileged access, not just that authentication events are logged.
PCI-DSS Requirement 10.2 requires implementing audit logs to reconstruct activities for all individual user access to cardholder data and all actions taken by any individual with root or administrative privileges. For database sessions on systems containing cardholder data, this explicitly requires query-level logging, not authentication-level logging.
AkkuReka is the session proxy component within Akku PAM. All privileged sessions are routed through AkkuReka rather than connecting directly to the target system. This proxy position means AkkuReka operates at the protocol layer between the authenticated user and the target, which is where the SMART Audit Trail data is generated.
For SSH sessions, AkkuReka captures a complete keystroke log per command, timestamped at the protocol level. Every command typed, every output returned, every file path referenced. The recording is structured per command as a discrete event with its own timestamp, making it searchable by command string rather than requiring review of a continuous recording.
For MySQL and PostgreSQL sessions, AkkuReka captures both a screen recording and a structured SQL query log as part of the SMART Audit Trail. Each query is stored as a discrete record with execution timestamp, query text, and result metadata.
For financial services organisations where PCI-DSS, RBI, and SEBI compliance requires evidence of database access at the query level, this is the specific evidence type those frameworks are asking for. The authentication log confirms who logged in. The SQL query log confirms what they did once connected.
For RDP sessions, AkkuReka captures full screen recordings at a configurable frame rate. For Kubernetes cluster access via kubectl, AkkuReka captures both a session event recording and a command log for kubectl operations. Kubernetes access is one of the most commonly excluded infrastructure categories from PAM deployments. The kubectl command log closes the same governance gap for container orchestration that SSH keystroke logging closes for Linux servers.
AkkuReka uses an outbound worker model. A lightweight worker process is deployed in the same network segment as the target systems. The worker initiates an outbound TLS 1.3 connection to the Akku cloud platform. No inbound ports are required on target systems or firewalls. No agent installation. No SSH configuration changes. Target systems require no modification.
For ITeS and BPO organisations where target systems include client-managed infrastructure that cannot be modified, and for manufacturing organisations with OT-adjacent infrastructure where agent installation is operationally constrained, the agentless outbound worker model means session recording coverage can extend to systems that would be excluded from an agent-based architecture.
SMART Audit Trail recordings are stored encrypted using AES-256-GCM in Akku’s audit storage layer. The storage is append-only. Recordings cannot be modified or deleted after they are written. The privileged user who ran the session has no access to the recording layer regardless of their privilege level on the target system. Even a user with root access on a Linux server cannot modify their recording because it is written to Akku’s audit storage at the proxy layer, outside the scope of any privilege the user holds on the target.
For each category of privileged session in your environment, answer this question: if a privileged user ran a command during a session last Tuesday that caused a problem, how many minutes would it take your security team to identify the specific command, the specific session, and confirm attribution to a specific individual?
If the answer requires accessing logs on the target system itself, and the user who ran the session had the ability to modify those logs, the evidence integrity is compromised before the investigation starts.
For Linux servers, check whether SSH sessions are being captured in SMART Audit Trails beyond the standard auth.log authentication events. For database servers, check whether query-level logging is enabled and whether those logs are stored in a tamper-evident location outside the database server itself.
See AkkuReka Session Proxy Architecture | Explore Akku PAM | Talk to the Akku Team
Q: What is the technical difference between an authentication log and a SMART Audit Trail?
A: An authentication log records events at the session boundary: the login event with actor identity, timestamp, source IP, MFA method, and authentication outcome, and the session termination event with timestamp and duration. It records that access occurred. A SMART Audit Trail records what happened during the session: every command executed, every query run, every file accessed, every configuration change made. ISO 27001 A.8.15 requires both: the authentication record for access accountability and the activity record for user activity logging. Most privileged access environments have built the first and not the second.
Q: What is the storage format for AkkuReka SMART Audit Trail recordings?
A: SSH keystroke logs are stored as structured text with per-command timestamps, searchable by command string across all sessions in a time period. RDP recordings are stored as compressed video at the configured frame rate. Database session recordings include both a screen capture and a structured SQL query log where each query is a discrete record with execution timestamp, query text, and result metadata. All recordings are encrypted at rest with AES-256-GCM and accessible through the Akku admin console or API under RBAC-controlled access.
Q: Does AkkuReka require any agent installation or configuration changes on target systems?
A: No. AkkuReka uses an outbound worker model. The worker process is deployed on a separate host in the same network segment as the target systems. Target systems require no modification, no agent installation, and no configuration changes. The only requirement is that the AkkuReka worker has network access to target systems on their native protocol ports and outbound HTTPS on port 443 to the Akku cloud.
Q: How does AkkuReka protect SMART Audit Trail recordings from tampering by the privileged user?
A: AkkuReka records sessions at the proxy layer, outside the target system and outside the user’s access scope. A user with root access on a Linux server cannot modify their recording because it is not stored on the target. The storage is append-only and tamper-evident by design.
Q: How does SMART Audit Trail recording support compliance with PCI-DSS Requirement 10?
A: PCI-DSS Requirement 10.2 requires logging of all individual user access to cardholder data and all actions by individuals with root or administrative privileges. For database sessions in the cardholder data environment, this requires SQL query-level logging. AkkuReka’s structured SQL query log for MySQL and PostgreSQL sessions captures each query as a discrete record with execution timestamp and query text, directly satisfying the Requirement 10.2 evidence standard.
Q: What is the forensic search capability for SSH session recordings?
A: AkkuReka indexes SSH session recordings by command string and timestamp. An investigator querying for a specific command across all sessions in a defined time window receives the sessions where the command appeared, the exact timestamp, and a link to the playback position. An investigation that would require reviewing hours of recordings can be completed through a command string query in minutes.
Your BYOD policy permits employees to access corporate applications from personal devices. The security team agreed to this because blocking…
When did your MDM platform last produce a complete list of every application installed on every enrolled device? Not the…
A provisioning record captures a point-in-time entitlement decision: this user was granted access to this application on this date. It…
If your SSO platform had a service disruption at 2am tonight, how would your team find out about it? For…
The IAM layer generates the earliest detectable signal of a credential attack. Before any account is compromised, before any privileged…
Defensible audit evidence for an access grant has a specific technical definition. It is not a confirmation that the access…