Akku

When you give someone SSH access to a Linux server, what exactly have you given them?

Think about that carefully before answering. Because the instinct is to say “access to do the thing they were brought in to do.” But what the SSH session actually provides, absent any command-level restrictions, is an interactive shell with whatever privileges the account carries. That is not the same thing. Not even close.

A developer given SSH access to restart a service has, in the same session, the technical ability to read log files, navigate the file system, view running processes, install packages if the account permits it, modify configuration files, and run any command the system allows for that user. The restart-the-service use case is a one-liner. The SSH session is a general-purpose compute environment.

Most organisations know this is true and treat it as acceptable risk. This blog explains why that calculation is wrong, and what enforcing least privilege at the command level actually looks like technically.

Where the Principle of Least Privilege Stops Short in Most Environments

Least privilege is well understood as a principle and inconsistently applied as a control. At the application layer, role-based access control is reasonably mature in most organisations. Users have the permissions their role requires, and access is reviewed periodically. At the server layer, the model collapses.

The reason is architectural. SSH provides an authenticated shell. Once the shell opens, what the user can do is governed by the Unix permission model on the target system, not by any IAM policy. The IAM system verified the identity. It has no further influence over what happens inside the session.

This means privileged access management that stops at session authentication is not enforcing least privilege. It is enforcing authenticated access, which is a different and weaker control. If you want to understand the full scope of what PAM is supposed to cover, the PAM explained blog covers the complete framework, including where session-level controls fit within the broader privileged access architecture.

There are two common approaches organisations use to address this within the Unix permission model, and both have significant limitations in enterprise environments.

sudo policy files. Restricting commands through the sudoers file on each target server is technically viable but operationally brittle. Every change to the permitted command set requires an update to the sudoers file on every affected server. In environments with dozens or hundreds of servers, this creates a configuration management burden that leads to inconsistency. Servers end up with different policies because updates are applied inconsistently. Over time, the gap between what the policy says and what is actually enforced on each server grows.

The deeper problem is that sudoers management happens at the server layer, disconnected from the identity and access management system. When a user’s role changes or they leave the organisation, the sudoers entries do not automatically update. This is the same offboarding gap that automated provisioning and de-provisioning address at the application layer, but misses entirely at the server layer when PAM is not in place.

Restricted shells. Rbash and similar restricted shell environments limit certain operations within the shell itself. They are easy to escape in ways that are well documented, and they are not a serious control in environments where the user has any technical sophistication.

Neither approach gives you what you actually need: per-user, per-server command restrictions managed centrally, enforced at the session layer, and connected to your IAM system so that changes propagate automatically.

What Happens When the Restriction Model Breaks Down

The risk is not abstract. Consider a third-party vendor brought in to perform database maintenance on a production server. They need to connect to the database service, run specific diagnostic queries, and restart a process if needed. The IT team grants SSH access to the relevant server.

During the session, the vendor is working on the task they were given. But nothing technical prevents them from exploring the file system, reading application configuration files that may contain connection strings for other systems, viewing the contents of log files that include user activity or transaction data, or running commands outside the scope of their engagement.

Most vendors would not do this deliberately. But the risk is not primarily deliberate misuse. It is the combination of accidental exposure and the absence of any audit evidence that would surface it. If the session produces only a login and logout timestamp, there is no record of what was accessed or explored. The SMART Audit Trails capability in Akku PAM closes this specific gap, capturing every command executed during an SSH session with a precise timestamp. But audit trails tell you what happened after the fact. Granular Access Control prevents what should not happen in the first place.

When a compliance audit asks you to demonstrate that your third-party vendor had access scoped to their specific task, an SSH session with no command restrictions and no command-level audit log does not satisfy that requirement. Not under ISO 27001 Annex A.9, not under DPDPA’s data processor governance requirements, not under the RBI Cybersecurity Framework’s privileged access monitoring requirements. For manufacturing organisations managing contractor access to OT-adjacent systems, or financial services firms operating under SEBI’s CSCRF, this is a documented audit gap, not a theoretical concern.

What Command-Level Restriction Actually Requires at the Architecture Level

Effective command-level restriction needs to satisfy three technical requirements simultaneously.

The restriction must be enforced at the session layer, not the server layer. Configuration on the target server is operationally unsustainable at scale and disconnected from the IAM system. The session proxy is the correct enforcement point because it sees every command before execution and has access to the identity and policy context.

The restriction must be per user per server. The same user on different servers may require different permitted command sets. Different users on the same server may require different permitted commands. A flat policy that applies the same restrictions to everyone on a given server does not map to real operational requirements.

The restriction must be connected to the identity system so that policy changes, role changes, and offboarding propagate automatically without a separate remediation step at the server layer.

How Akku PAM Enforces This

Granular Access Control in Akku PAM allows administrators to define a permitted command list for each user on each SSH server, configured from the Akku Admin Console. Different users on the same server can have different permitted command sets. The same user on different servers can have different permissions.

Enforcement happens at the AkkuReka session layer. When the user executes a command inside the SSH session, it is checked against their permitted list in real time before execution on the target server. If the command is permitted, it executes normally. If it is not on the list, it is blocked at the point of execution, regardless of the user’s underlying system privileges on the server. This requires no agent on the target server and no changes to the server configuration.

Because enforcement happens at AkkuReka rather than the server layer, changes to permitted command lists propagate immediately across every server in scope. There is no sudoers file to update, no configuration management job to run, no inconsistency between servers.

SMART Audit Trails capture every command executed during the session, including every command that was attempted and blocked, with a precise timestamp. The combination of Granular Access Control and SMART Audit Trails provides two things neither delivers alone: technical enforcement of the intended access scope, and a complete logged record of how that scope was used. Both are exportable as compliance evidence for ISO 27001, RBI, DPDPA, SOC 2, and PCI-DSS requirements.

The just-in-time access layer adds another dimension on top of command-level restriction. Rather than granting standing SSH access that persists indefinitely, JIT access means elevated access is requested, approved through a configurable chain, granted for the duration of the task, and automatically revoked when the session ends. When you combine JIT access with Granular Access Control, the result is privileged access that is time-bounded, scope-bounded, and command-bounded simultaneously.

The security hardening and zero-trust posture layer applies across every session that AkkuReka governs: adaptive MFA, MDM device compliance enforcement, IP and location restrictions, and time-of-day policies. The same policy engine that governs access to your SaaS applications governs access to your servers. There is no separate security posture for infrastructure versus applications.

When an employee or contractor is offboarded from Akku IAM, their infrastructure access is revoked immediately through AkkuReka. The permitted command lists are irrelevant at that point because the session proxy will not open a session for a deprovisioned identity. There is no separate step at the server layer.

For organisations with third-party vendor access to production infrastructure, Granular Access Control enables a specific capability that is otherwise architecturally difficult to achieve: contractors and vendors can be given SSH access scoped precisely to the tasks they need to perform, with a technical boundary preventing them from exceeding that scope. This is directly relevant for ITeS and BPO organisations managing vendor access to client environments, and for manufacturing organisations where third-party maintenance contractors regularly need server access scoped to specific operational tasks.

Before You Move On

Pull the sudoers configuration from three production servers in your environment. For each server, answer these questions.

Does the current configuration accurately reflect the minimum commands each user requires for their current role, or does it reflect the configuration that was set up when the server was provisioned and has not been meaningfully reviewed since?

If a contractor completed their engagement six months ago and their account was disabled in Active Directory, do the sudoers entries on these servers still reference their account?

If a user exceeds their intended scope during an SSH session today, where in your current logging setup would that show up?

If the policy on these servers needed to change tomorrow, how many systems would you need to update manually, and how confident are you that the update would be applied consistently across all of them?

See How Akku PAM Granular Access Control Works | Talk to the Akku Team

Questions Infrastructure and Security Teams Ask About Command-Level Access Control

Q: Why is SSH access considered all-or-nothing even when role-based access control is in place at the application layer?

A: RBAC at the application layer controls what users can do within applications. SSH access operates at the operating system layer, below the application. Once an SSH session is open, the user has an interactive shell governed by Unix file permissions and sudo policies on the target server, not by any IAM policy. The IAM system verified the identity at the point of authentication and has no further influence inside the session. Least privilege at the application layer and least privilege at the server layer are two separate and independent controls.

Q: What are the limitations of using sudoers files to restrict commands?

A: The sudoers approach works in principle but fails operationally at scale. Every change to the permitted command set requires updating the sudoers file on every affected server individually. In environments with dozens or hundreds of servers, this creates configuration drift where the effective policy on each server diverges from the intended policy over time. Sudoers management is also disconnected from the IAM system, meaning that role changes and offboarding do not automatically propagate to server-level command restrictions. AkkuReka enforces command restrictions centrally at the session proxy layer, eliminating both the configuration drift problem and the IAM disconnection problem.

Q: How does command-level restriction differ from session recording?

A: Session recording captures what happened. Command-level restriction prevents what should not happen. Recording tells you after the fact that a user ran a command they were not supposed to run. Restriction blocks the command before it executes. SMART Audit Trails handle recording. Granular Access Control handles restrictions. Together, they provide enforcement plus forensic evidence.

Q: Does command-level restriction require installing an agent on target servers?

A: Akku PAM’s Granular Access Control does not require any agent on target servers and no changes to server configuration. Enforcement happens at the AkkuReka session proxy layer, which intercepts every command before it reaches the target server. The server receives only commands that passed the permitted list check.

Q: How are permitted command lists managed when contractors or third-party vendors need temporary access?

A: Permitted command lists are configured per user per server from the Akku Admin Console. For a contractor engagement, the administrator creates a list specific to that contractor on the specific servers they need to access. Just-in-time access can be layered on top, so the access is also time-bounded. When the engagement ends, and the contractor’s IAM identity is deprovisioned from Akku IAM, AkkuReka stops opening sessions for that identity immediately. No separate cleanup of server-level configurations is required.

When did you last rotate the root password on your most critical production server?

Not when it was scheduled. Not when the policy says it should have been. When it actually happened, with a documented record, and with every system that depended on that credential updated at the same time.

If that question made you pause, you are not alone. And the pause itself is the problem, because an attacker or an auditor is not going to wait for you to work out the answer.

Most infrastructure teams carry this risk quietly. Not because they are careless, but because the operational cost of rotating credentials manually across a production environment is high enough that it gets deferred, and deferred again, until the password that was set during initial provisioning is still running in production two years later.

This blog covers what that actually means at the infrastructure layer, where the failure modes are specific, where they hide, and what it takes to close them properly.

The Three Ways Static Credentials Fail, and None of Them Are Obvious Until Something Goes Wrong

SSH keys that outlive the people who hold them. Disabling an Active Directory account does not revoke SSH access on Linux servers. The two authentication systems operate independently. The server’s authorized_keys file holds public keys that are trusted for connection regardless of whether the corresponding identity is active in any directory service. Unless the public key is explicitly removed from authorized_keys on every target server, a former employee’s SSH key remains valid indefinitely after their AD account is disabled.

In environments with dozens or hundreds of servers, this removal step is almost never done consistently. The result is a standard offboarding process that appears complete, AD account disabled, email deactivated, VPN revoked, while SSH access to production infrastructure persists untouched. This is exactly the kind of gap that automated provisioning and de-provisioning is designed to eliminate, but only when the provisioning system is connected to the infrastructure access layer, not just the application layer.

Service account passwords embedded in configuration files. Database connection strings, API service accounts, and application configuration files frequently contain static credentials. Rotating them requires updating every instance simultaneously, testing that nothing breaks, and coordinating a deployment. The operational cost is high enough that most teams do it infrequently. The password that was set during the initial deployment is often the password running in production three years later, embedded in config files across multiple servers, known by everyone who has ever touched the deployment pipeline.

Jump server credential passthrough. In environments using a bastion host, the jump server frequently holds static credentials to target systems. The user authenticates to the jump server, and the jump server authenticates to the target using credentials stored in its own configuration. From the user’s perspective, access appears controlled. From a security perspective, the target credentials exist in plaintext in the jump server’s configuration, accessible to anyone who can extract them from memory during an active session or read them from the configuration store directly.

What a Credential Compromise Looks Like From the Inside, and Why It Is Hard to Detect

The incident does not start with an alert. It starts with an anomaly. A dataset that looks wrong. A configuration file that has been modified. A process running that was not there yesterday.

The investigation team pulls the access logs. They have authentication events: timestamps, source IPs, and session durations. What they do not have is command-level attribution within sessions. They can establish that a specific service account authenticated to a server during a specific window. They cannot establish what that account did once the session opened, because the logging was never configured at that depth.

This is the visibility gap that SMART Audit Trails address directly. Every SSH command executed during a privileged session is captured with a precise timestamp, automatically, tamper-proof, and searchable. But that audit trail only exists if the session ran through a governed proxy. Static credentials used through a jump server or direct SSH connection produce no such record.

The investigation then tries to attribute the service account to a specific individual. This is where static shared credentials produce their most damaging consequence. When a password has been held by multiple people over time, with no rotation log to establish which version was active at any given moment, the attribution chain collapses. The investigation cannot prove who was responsible. It cannot prove that an unauthorised party was involved either. It produces no conclusion.

For regulated organisations, this is not just an operational failure. The RBI Cybersecurity Framework requires privileged access monitoring and audit trails that support forensic investigation. DPDPA requires data fiduciaries to demonstrate accountability over access to personal data. ISO 27001 Annex A control A.9.4 requires that access to privileged utility programs is restricted and controlled. An inconclusive investigation is evidence that none of these controls were operating effectively.

What Actually Fixing This Requires at the Architecture Level

The answer is not a stricter password policy. A policy requiring 90-day rotation on a 200-server estate still depends on a person doing the work, updating every dependent system, and documenting the change. It fails the moment the person is unavailable, the process is skipped, or the dependency map is incomplete.

Closing this gap requires three things to be true simultaneously.

Credentials must be stored in a central encrypted vault with no local copies, no configuration file embeddings, and no human-readable form outside the vault itself. Every retrieval event must be logged.

Rotation must be automated and independent of human scheduling. The credential changes on a defined interval. The vault stores the new value. Every system that needs the credential retrieves it from the vault at runtime rather than holding a cached copy.

Credential injection must happen at the session layer, not the user layer. This is the architectural distinction most credential management tools miss. Giving a user a rotated password from a vault still gives the user a password. They can copy it, photograph it, or retain it after rotation. True credential security requires that the user never receives the credential at all. The zero-trust session proxy injects it directly into the connection at the protocol layer. The user connects. The credential exchange happens between the proxy and the target system. The user never sees it.

When these three layers work together, the credential never exists in human-accessible form at any point in the session lifecycle. This is the architecture behind enforcing zero-trust access security at the infrastructure level.

How AkkuArka and AkkuReka Implement This

AkkuArka is the credential vault and rotation engine at the core of Akku PAM. Every privileged credential across the infrastructure, server passwords, SSH keys, database credentials, service account passwords, is stored and encrypted centrally. There is no local credential storage, no per-server password management, and no credential distribution to endpoints.

Rotation is automated on a configurable schedule. When rotation runs, AkkuArka generates the new credential, updates the target system, stores the encrypted value in the vault, and invalidates the previous credential. No IT intervention required. No deployment coordination. No risk of a partially updated environment where some instances still hold the old credentials.

For database access, AkkuArka goes further than password rotation. Rather than rotating a shared service account password, it generates a unique throwaway user for every single database session. For PostgreSQL, MySQL, and MongoDB, a new role is created at the point of the access request, scoped with the minimum permissions required for that session. When the session closes, the role is dropped. There is no persistent shared database credential in any form. Every session is isolated by design. This is what just-in-time access looks like applied to credentials, not just sessions.

AkkuReka is the zero-trust session proxy that handles credential injection. When an administrator requests a session, AkkuReka verifies identity through Akku IAM, checks device compliance, evaluates contextual access policies including IP, location, and time of day, and checks approval status if a just-in-time workflow is configured. Only when all conditions are satisfied does AkkuReka open the session.

The credential injection happens at the protocol layer within AkkuReka. For SSH sessions, AkkuReka handles key injection transparently. The administrator opens a browser-based terminal through AkkuReka. The connection to the target server uses credentials retrieved from AkkuArka and injected into the SSH handshake. The administrator never sees the key. Every command executed in the session is captured with a precise timestamp through SMART Audit Trails, tamper-proof and searchable by user, command, server, or time window.

The offboarding gap closes automatically. When an employee is offboarded from Akku IAM, their access to all privileged systems is revoked at that moment. Because access is mediated through AkkuReka rather than direct SSH key authentication, removing the IAM identity terminates infrastructure access immediately. The authorized_keys file on target servers does not need individual updates. There is no window between HR offboarding and IT revocation where a departing employee retains live access.

This matters particularly for manufacturing organisations managing contractor access to OT-adjacent systems and financial services firms where RBI and SEBI audit obligations require documented credential lifecycle management. In both cases, the risk of a former employee or contractor retaining active server credentials is a compliance finding, not just a security concern.

If you want to understand how privileged access management fits into the broader infrastructure security framework, the PAM explainer on the Akku blog covers the full architecture in detail. For teams managing PAM across cloud and hybrid environments, specifically, the PAM in cloud and hybrid environments blog covers the deployment considerations that apply across mixed infrastructure estates.

The Four Questions Worth Asking Before You Move On

Pick your three most critical production servers and answer these honestly.

Can you produce a documented rotation record for every credential used to authenticate to these servers in the last ninety days?

For every authentication event in that period, can you show command-level attribution, not just which account connected, but what that account did inside the session?

If a former employee who left in the last twelve months attempted to authenticate using SSH keys they held before their departure, would the attempt succeed?

Are any service account passwords embedded in configuration files on these servers currently shared with other systems or individuals?

If any of those produced an uncertain answer, the gap between your current posture and what a forensic investigation or compliance audit requires is not theoretical. It is live, right now, in your infrastructure.

See How Akku PAM Works | Talk to the Akku Team

Questions Infrastructure and Security Teams Ask About Server Credential Management

Q: Why does disabling an Active Directory account not revoke SSH access to Linux servers?

A: SSH key-based authentication on Linux servers operates independently of Active Directory. The server’s authorized_keys file holds public keys trusted for authentication regardless of whether the corresponding identity is active in any directory service. Unless the public key is explicitly removed from authorized_keys on every target server, or unless SSH access is gated through a proxy like AkkuReka that enforces IAM state in real time, a disabled AD account does not affect SSH connectivity. This is the most common and least-discussed credential persistence gap in hybrid infrastructure environments.

Q: What is the technical difference between rotating a database password and using per-session throwaway users?

A: Password rotation changes a shared credential on a schedule. Every application, script, and service connecting to the database using that credential must be updated simultaneously, or the connection fails. Throwaway users solve the problem at a different layer. A unique database role is created for each session with permissions scoped to that task, then dropped when the session closes. For PostgreSQL, MySQL, and MongoDB, AkkuArka handles role creation and expiry automatically at the point of each session request.

Q: How does credential injection work at the SSH protocol layer without the user seeing the key?

A: When a session is opened through AkkuReka, the session proxy handles the SSH handshake to the target server directly. AkkuReka retrieves the current credential from AkkuArka, uses it to authenticate to the target on behalf of the session, and presents the user with a proxied terminal connection. The credential is used in the protocol exchange between AkkuReka and the target server. It is never transmitted to the user’s endpoint and never appears in the user’s session context.

Q: How are service account passwords embedded in application configuration files handled?

A: AkkuArka addresses this by becoming the credential source at runtime rather than at deployment time. Instead of embedding a static password in a configuration file, applications retrieve the current credentials from AkkuArka at the point of connection. When AkkuArka rotates the credential, the application automatically retrieves the new value on its next connection attempt. There are no stale configuration files holding old credentials, and no coordinated deployment is required when rotation occurs.

Q: What compliance frameworks specifically require privileged credential management controls?

A: ISO 27001 Annex A control A.9.4 requires restriction and control of access to privileged utility programs, including credential management. The RBI Cybersecurity Framework requires privileged access management controls covering credential governance and audit trails for scheduled commercial banks. DPDPA requires data fiduciaries to implement appropriate technical measures to protect personal data. SOC 2 Trust Services Criteria CC6.1 through CC6.3 cover logical access controls, including privileged account management. PCI-DSS Requirement 8 specifies rotation intervals and shared credential prohibitions. Akku PAM is built to satisfy all of these. See the compliance coverage on the Akku PAM page for the full breakdown.

If you are currently evaluating Privileged Access Management solutions, there is a question worth asking the vendors in your shortlist: what is this product actually built on?

Not every PAM solution on the market was built from the ground up as a PAM platform. Some are remote desktop gateways with PAM features bolted on. Some are built on top of open-source tools like Apache Guacamole, a browser-based access gateway that was never designed for privileged access management.

That distinction matters more than most buyers realise. Here is why.

What Apache Guacamole Actually Is

Apache Guacamole is a free, open-source, clientless remote desktop gateway maintained by the Apache Software Foundation. It allows users to access servers via SSH, RDP, VNC, and Telnet through a web browser, with no client software installed.

It is a well-built tool for what it was designed to do: give administrators browser-based access to infrastructure without a VPN. Many IT teams deploy it as a jump server or bastion host. At zero licensing cost, it is an attractive starting point.

But it is a starting point, not a destination for organisations with real security or compliance requirements.

The Problem With Calling It PAM

The term Privileged Access Management describes a specific set of security controls: dynamic credential management, session approval workflows, adaptive multi-factor authentication, compliance-ready audit trails, and least-privilege enforcement. These are the capabilities auditors look for when they assess your PAM posture for SOC 2, ISO 27001, PCI-DSS, RBI, or DPDPA.

Apache Guacamole provides none of these natively.

It records sessions. It logs who connected and when. It can integrate with LDAP for authentication. But credentials are stored statically in its connection configuration, meaning someone in your IT infrastructure knows the actual server password, or it exists in a file that could be accessed. There is no credential vault that generates dynamic, per-session credentials. There is no approval workflow that stands between a user’s request and the target server. There is no adaptive MFA that escalates when a login comes from an unfamiliar device.

This is not a criticism of Guacamole. It was not designed to be a PAM platform. The issue arises when a product built on Guacamole is sold as one.

What a Gateway-Based ‘PAM’ Cannot Do

Credential Security

In a genuine PAM platform, users never see or handle the target credentials. The platform generates a unique, short-lived credential for each session, injects it silently into the proxied connection, and destroys it when the session ends. There is nothing to leak because there is nothing the user ever knows.

In a Guacamole-based solution, credentials are pre-configured and stored statically. The system passes them through, but they exist in a form that can be accessed, extracted, or exposed. Password rotation is manual. A departing administrator who knew a server password still knows it after you delete their account from the gateway.

Session Governance

A PAM platform includes a session approval workflow: a user requests access, an administrator reviews and approves, and only then does the session open. This provides a human checkpoint for every privileged action on critical infrastructure.

Guacamole has no approval workflow. A user with connection access connects immediately. The audit trail tells you what happened, but nothing prevented it from happening.

Database Access

Guacamole does not support database sessions at all. For organisations where database administrators access PostgreSQL, MySQL, or other systems, a Guacamole-based solution provides zero visibility into what SQL queries were executed during a session, a direct gap in any audit that asks for database activity logs.

A purpose-built PAM platform proxies database sessions and captures every query, timestamped and structured, alongside the session recording.

Compliance Evidence

When an auditor asks for evidence of privileged access controls, they are looking for dynamic credential management, session approval records, searchable audit trails, and adaptive MFA. Guacamole can provide a session recording and a connection log. It cannot provide the rest.

For teams pursuing SOC 2, ISO 27001, PCI-DSS, or India’s RBI Cybersecurity Framework and DPDPA requirements, this gap requires additional tooling, tooling that typically costs more than a purpose-built PAM platform would have in the first place.

How to Tell What You Are Actually Buying

When evaluating a PAM solution, ask these questions directly:

• Does the platform generate dynamic, per-session credentials, or does it store static credentials in connection configuration?
• Do users ever see, know, or handle the actual target password, or is credential injection completely invisible to them?
• Is there a session approval workflow where a human must explicitly authorise access before a session opens?
• Does the platform proxy database sessions (MySQL, PostgreSQL) and capture SQL query logs, or only SSH and RDP?
• Is MFA adaptive, does it escalate based on device, location, IP, or time, or is it binary on/off?
• If you remove a user from the identity platform, is their access to all privileged systems revoked immediately, or does the gateway need to be updated separately?
  

If the answers reveal a gateway with credential pass-through and no approval workflow, you are looking at infrastructure access tooling, not a PAM platform.

What Akku PAM Is Built On

Akku PAM was designed from the ground up as a Privileged Access Management platform, not adapted from a remote desktop gateway. It is built around two purpose-built components.

AkkuArka is the credential vault. It generates a unique credential for each privileged session, server passwords, database users, SSH keys, at the moment access is requested. When the session ends, the credential expires. There are no static passwords in configuration files. There is nothing for a user to know or leak.

AkkuReka is the session proxy. Every privileged connection, SSH, RDP, database, Kubernetes, passes through AkkuReka. Before a session opens, AkkuReka verifies the identity, the device, the location, the IP, the time of day, and the approval status. The session is recorded end to end. Every SSH command, every SQL query, every RDP action is captured, timestamped, and stored in SMART Audit Trails, tamper-proof and fully searchable.

The result is a privileged access architecture where users connect to critical systems without ever knowing the password, every session requires explicit verification, and every action leaves a complete, searchable audit trail.

For organisations with compliance obligations, or for IT teams that simply want to know, with certainty, what is happening on their infrastructure, that is the difference between a remote desktop gateway and a PAM platform.

The Bottom Line

Apache Guacamole is a capable, free, open-source tool. If browser-based server access with basic session recording is all you need, and compliance, credential security, and audit trails are not requirements, it does its job.

But if a PAM solution is being positioned to you as meeting your compliance and security requirements, and it is built on or compared to a remote desktop gateway, the gap between what it promises and what it can actually prove in an audit is worth understanding before you sign.

Ask the six questions above. The answers will tell you what you are actually buying.

See How Akku PAM Works | Talk to the Akku Team

Questions We Hear Most From IT and Security Teams

Q: Is Apache Guacamole a PAM solution?

A: No. Guacamole is a remote desktop gateway. It provides browser-based access to servers but does not include a credential vault, dynamic credential generation, session approval workflows, or adaptive MFA. These define a Privileged Access Management platform.

Q: Can a Guacamole-based solution meet PAM compliance requirements?

A: Partially, and only with significant additional tooling. Guacamole provides session recording and a connection log, which satisfies some audit requirements. But dynamic credential management, session approval workflows, database session logging, and adaptive MFA require either purpose-built additions or a separate platform.

Q: What is the difference between a remote desktop gateway and a PAM platform?

A: A remote desktop gateway provides access to servers via browser or proxy. A PAM platform governs, records, and controls everything about that access: who approved it, what credentials were used, what actions were taken, and whether those credentials still exist after the session ended. The gateway gets you in. The PAM platform is accountable for what happens once you are.

Q: How does Akku PAM handle privileged session access?

A: Every privileged session passes through AkkuReka, which verifies identity, device, location, IP, and approval before opening the connection. AkkuArka generates a unique credential for the session, one the user never sees, and destroys it when the session ends. Every action is recorded and logged in SMART Audit Trails, searchable by user, command, system, or time window.

Q: Does Akku PAM require complex infrastructure like Guacamole?

A: No. Akku PAM deploys a lightweight worker near your target infrastructure. No Tomcat, no guacd, no database to manage. Most organisations are live within hours to a few days without specialist infrastructure expertise.

You probably think you know what your admins are doing on your servers. Here is what your logs are actually showing you.

A name. A timestamp. A session duration.

That’s it.

Forty-one minutes on a production server, and your audit trail tells you someone was there. It doesn’t tell you what they typed. What they changed. What they looked at. Whether they ran one command or fifty. Whether anything that happened in those forty-one minutes is the reason your environment looks the way it does today.

Sound familiar? It should, because this isn’t a rare edge case. It’s the default state for most IT environments, and most teams don’t realise it until something breaks and they go looking for answers that aren’t there.

Three Real Scenarios Worth Examining

Here are three scenarios. See if any of them have happened in your organisation.

Scenario one:

A contractor was brought in for a three-week infrastructure project. They were given SSH access to two production servers. The project ended, HR offboarded them, and their email was deactivated. Six months later, during a routine review, you find their SSH key is still live. You want to know how often they connected after the project ended and what they did. Your logs show connection events. That is all.

Scenario two:

Your senior DBA ran a maintenance job last Friday night. The session lasted two hours. Monday morning, a business team reports that a dataset looks wrong. Rows that should be there are not. You pull the logs. You can confirm the DBA was connected. You cannot see a single query they ran.

Scenario three:

A developer needed production access to restart a service. It was meant to take ten minutes. The session lasted forty-five. You approved the access, you can see the login and logout times, and you have no idea what else they did while they were in there.

None of these is hypothetical. These are the conversations happening in security post-mortems across mid-market organisations right now. And in each case, the team investigating the incident hits the same wall. They know who was there. They can’t tell you what happened.

The Root Cause Is Architectural, Not Operational

It’s not because your team isn’t doing their job. It’s because the tools most organisations use for infrastructure access were built for connectivity, not governance.

A VPN gets your admin to the network. A jump server creates a single pathway. Direct SSH authentication proves identity. None of these was designed to record what happens after the connection opens. They get the person in the room. They don’t watch what the person does inside it.

And honestly, for a standard user accessing a business application, that’s probably fine. The application itself logs activity. The scope of what they can do is bounded.

But privileged users are a different conversation entirely. A sysadmin on a production server can modify configurations, delete files, install scripts, change permissions, and exfiltrate data, all in a single session. A DBA with direct database access can run queries that touch millions of records. A DevOps engineer with Kubernetes access can make changes that won’t surface as problems for days.

The result? Privileged account security is the most under-governed area in most IT environments. You have more documented visibility into what a junior analyst does in your CRM than into what your most trusted infrastructure admins do on your most critical systems.

That’s not a comfortable thing to sit with.

Where the Absence of Session Visibility Becomes a Business Risk

Post-incident investigations:  Something breaks. You need to know what changed and when. Without command-level logs, you are working backwards from symptoms. What should take an hour takes days. Sometimes you never find the answer. And ‘we can see someone was logged in, but we don’t know what they did’ is not an acceptable conclusion when you are explaining an incident to leadership or a regulator.

Compliance and audit requirements:  Whether your obligations sit under ISO 27001, RBI’s Cybersecurity Framework, SEBI’s CSCRF, HIPAA, or India’s DPDPA, the requirement is consistent. You need to be able to demonstrate what privileged users did, not just that they authenticated. ‘We have login records’ gets you through the basic check. It does not satisfy a forensic audit. Auditors are getting better at knowing the difference.

Insider threat detection:  This one’s uncomfortable but worth saying plainly. Your most dangerous insider threat isn’t someone trying to break in from outside. It’s someone who already has legitimate access and uses it in ways they shouldn’t. Detecting that requires knowing what normal behaviour looks like for each privileged user, and building that baseline is impossible if you’re not logging what they do in every session. Right now, if an admin is misusing their access, you might find out eventually. But you won’t find out from your logs.

What Session-Level Accountability Looks Like in Practice

Privileged session monitoring, done properly, operates at a level below authentication events. It captures what happens inside the session itself.

For SSH sessions, that means every command is logged individually with a precise timestamp, automatically, with no setup required on the target server. You can search it later by user, by command, by server, or by time. If something changed, you can find out exactly when and exactly what was run.

For RDP sessions, it means full session recording, a video-playback record of what happened on screen during the session. No more guessing. No more reconstructing from system logs that weren’t built for forensic investigation.

For database access, it means query logging. Every query, every session, every user. That Friday night maintenance job? You’d have a complete record of every statement that ran.

This is the difference between knowing someone was in the room for forty-one minutes and knowing what they did in every minute of it.

Akku PAM is built on this model, where no privileged session reaches your infrastructure unrecorded. But the more immediate question is whether your current setup can answer what we are about to ask.

A Practical Diagnostic for Your Current Environment

Pick any privileged session from the last thirty days in your environment. A sysadmin on a server, a DBA on a database, and a contractor who was given temporary access.

Now answer these:

• What commands did they run?
• What files did they access or change?
•  Can you produce a timestamped record of every action they took during that session?

If you’re hesitating on any of those, your audit trail ends at the login event. You know the door opened. You don’t know what happened inside.

That’s the gap. And now you know it’s there. 

Complete session visibility across SSH, RDP, and database access. Every command. Every query. Every action. Recorded automatically, searchable instantly, ready for the moment you need it.

See How Akku PAM Works | Talk to the Akku Team