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.
