Trading infrastructure audit readiness depends on identity attribution

At a glance

What this is: This is a practitioner analysis of why trading infrastructure struggles to produce audit-ready evidence across SSH, Kubernetes, databases, and RDP, with identity attribution as the core finding.

Why it matters: It matters because IAM, PAM, and NHI programmes in regulated environments must prove who did what across heterogeneous systems, not just issue access.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.

👉 Read Teleport's analysis of audit-ready identity attribution across trading infrastructure

Context

Trading infrastructure becomes hard to audit when identity, privilege, and session activity are recorded in separate systems that were never designed to agree on who actually performed an action. In practice, SSH keys, shared kubeconfigs, database usernames, and RDP service accounts turn an access event into a forensic puzzle instead of a clean control record.

That gap matters most in regulated environments where PCI DSS, ISO 27001, SOC 2, and financial oversight expect immutable proof of privileged activity. For IAM, PAM, and NHI teams, the issue is not whether logs exist, but whether they can be joined into a defensible identity chain without manual reconstruction.

Key questions

Q: How should trading firms make privileged sessions audit-ready across SSH, Kubernetes, databases, and RDP?

A: They should design the access path so every privileged session is tied to one identity from authentication through session termination. That means per-user credentials, correlated IdP and workflow logs, and session-level recording for commands, queries, and interactive actions. If auditors cannot reconstruct who did what without manual stitching, the audit model is still broken.

Q: Why do shared kubeconfigs and shared database users create compliance risk?

A: Shared credentials collapse attribution. A log may show that an account accessed a pod or queried a table, but it does not prove which person or machine was responsible. In regulated environments, that weakens evidentiary value because the control objective is not just access control, it is defensible identity attribution.

Q: What breaks when SSH keys are used as standing privileged access in trading environments?

A: Standing SSH keys create a gap between access and accountability. They can be copied, reused, and left valid long after the original need has passed, so the audit trail records key acceptance rather than accountable use. That makes it difficult to answer basic incident and compliance questions with confidence.

Q: Which control framework best fits audit evidence design for trading infrastructure?

A: NIST Cybersecurity Framework 2.0 is useful for organising the problem around govern, identify, protect, detect, respond, and recover, while identity-specific controls should focus on access attribution and privilege management. The right approach is to treat audit evidence as part of access governance, not a separate reporting layer.

Technical breakdown

Why SSH keys and bastion logs fail identity attribution

SSH on bare-metal systems often sits outside cloud-native telemetry, so the audit trail is split between the host, the bastion, and whatever identity system granted the key. A shared SSH key proves that a credential worked, not which person used it, and keys typically carry standing privilege, do not expire, and can be copied between engineers. That combination creates a structural attribution gap. When the session is recorded only as key acceptance on a server, the log cannot answer the auditor's real question: who initiated the command sequence?

Practical implication: Replace shared SSH keys with per-identity, short-lived access so host logs can be tied to a specific person or machine.

Kubernetes audit logs record credentials, not always the operator

Kubernetes audit events are useful, but they often identify the service account or kubeconfig used to authenticate rather than the exact person behind the session. In trading environments, centralised cluster access commonly leads to shared kubeconfigs, which means several engineers can appear as the same identity in the audit record. The result is a log that shows what namespace, pod, and timestamp were involved, but not who made the decision to exec into production. Correlation with IdP and access workflow data is therefore mandatory if the firm needs defensible attribution.

Practical implication: Correlate Kubernetes audit events with identity provider and access-request records before relying on them for compliance evidence.

Database and RDP logs need session-level identity, not account names

Database and RDP systems create another layer of ambiguity because native logs usually stop at the account that authenticated, not the operator's full context. A shared database user can query sensitive records without exposing the human responsible, and Windows Event Logs can show an RDP login while revealing nothing about actions taken inside the session. For auditors, that means a login event is not evidence of control. The missing piece is session recording and identity binding, so commands, queries, and desktop actions are attributable rather than inferred.

Practical implication: Treat database and RDP sessions as evidentiary objects, with recording and attribution built into the access path.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Audit readiness is an identity problem before it is a logging problem. The article shows that trading firms often have logs, but they do not have evidence that binds privileged activity to a single accountable identity across SSH, Kubernetes, databases, and RDP. That is a governance failure, not a tooling shortage. Auditors do not need more raw events, they need an unbroken identity chain from authentication to action to session end, which is the real control objective for regulated infrastructure.

Shared credentials create an evidence blind spot that traditional IAM reporting cannot close. A shared kubeconfig, a shared database user, or a reused SSH key can all satisfy access requirements while destroying attribution. That breaks the assumption that access logs are inherently auditable simply because they exist. Shared credential attribution gap: this is the specific failure mode the article exposes, and it should be treated as a programme-level defect in NHI governance and PAM design.

For trading firms, audit evidence must be produced at the moment of access, not reconstructed after the fact. When identity, privilege, and session data live in separate systems, every audit request becomes a manual correlation exercise with weak assurance at the end. That pattern scales poorly in high-frequency environments where access is frequent and short-lived. The implication is clear: evidentiary integrity has to be designed into the access path itself, not layered on afterward.

Unified auditability is now a cross-domain requirement, not a point control for one protocol. SSH, Kubernetes, databases, and RDP all fail in different ways, but the governance issue is the same. Control design has to recognise that NHI and human operators can both sit behind the same operational session, and that compliance evidence must survive across all of them. Practitioners should read this as a demand for identity-centric audit architecture, not another logging project.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• Forward view: The NHI Lifecycle Management Guide shows why lifecycle control, not just logging, is what keeps audit evidence defensible across service accounts and credentials.

What this signals

Shared identity is the hidden audit debt in regulated infrastructure. Once a firm allows one credential to represent many operators, every downstream log becomes less evidentiary and more interpretive. That problem does not stay confined to trading systems; it shows up wherever human and machine actors share access paths, including NHI-heavy infrastructure that still depends on manual correlation.

With 79% of organisations having experienced secrets leaks and 77% of those incidents causing tangible damage, per the Ultimate Guide to NHIs, the operational signal is clear. Firms that cannot trace privilege to a named identity should expect both audit friction and incident response delays to rise together.

Identity-centric audit design: firms should treat evidence collection as a control plane problem, not a back-office compliance task. That means aligning session recording, access approval, and privilege issuance so compliance teams can answer auditors without rebuilding the event from fragments.

For practitioners

• Eliminate shared administrative credentials Assign per-user or per-machine access for SSH keys, kubeconfigs, database users, and RDP accounts so every privileged session can be tied to one accountable identity.
• Bind session logs to upstream identity events Correlate IdP authentication, access requests, and downstream session records so auditors can follow one identity chain instead of reconciling disconnected log sources.
• Record session activity at the command level Capture SSH commands, Kubernetes exec activity, database queries, and interactive desktop actions as replayable events rather than treating logon events as sufficient evidence.
• Centralise evidence export for audit and SIEM use Make audit logs queryable in one place and exportable to detection platforms so compliance teams and security analysts work from the same structured record.

Key takeaways

• Trading firms fail audits when privileged actions cannot be tied to a specific identity across SSH, Kubernetes, databases, and RDP.
• Shared credentials and disconnected logs create an evidence gap that auditors can immediately see, even when access controls appear functional.
• The practical fix is identity-bound session recording, not more log volume or manual reconstruction after the fact.

Key terms

• Identity Attribution: Identity attribution is the ability to prove which specific person or machine performed a privileged action. In regulated environments, it is stronger than simple authentication because it connects the session, the credential, and the downstream activity into one defensible evidence chain.
• Unified Audit Trail: A unified audit trail combines events from multiple systems into one record with consistent identity, time, and privilege metadata. For trading infrastructure, that means SSH, Kubernetes, databases, and RDP can be reviewed as one chain of action instead of separate, partially useful logs.
• Standing Privilege: Standing privilege is access that remains available without a fresh, task-scoped approval or short-lived credential. In this context, it weakens auditability because the same credential can be reused across sessions, making it harder to prove who acted and whether the access was still justified.
• Session Recording: Session recording captures the actual commands, queries, or desktop actions taken after login. It matters because a logon event alone rarely answers the auditor's question. The record must show what happened during the session, not just that the session existed.

What's in the full article

Teleport's full blog post covers the operational detail this post intentionally leaves for the source:

• The exact log fields and session artifacts Teleport says auditors can use to trace SSH, Kubernetes, database, and RDP activity.
• The example audit records for Linux auth logs, Kubernetes API events, PostgreSQL queries, and Windows Security Event Logs.
• The mechanics of short-lived session certificates and how they change the evidence chain for privileged access.
• The case study details for Exness, including how hundreds of clusters are attributed to cryptographic identities.

👉 Teleport's full post covers the session recording model, evidence export flow, and Exness case study details.

Deepen your knowledge

Identity attribution across SSH, Kubernetes, databases, and RDP is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are trying to make regulated infrastructure audit-ready, it is a strong place to start.