How should security teams manage database and infrastructure access without relying on shared secrets or standing credentials?

Security teams should broker access through identity-aware controls that bind each session to a real person, a reason, and a time window. That approach reduces password sharing, improves accountability, and keeps access tied to the resource rather than the broader network. For sensitive systems, make access short-lived, approval-based, and logged so review and rollback are possible later.

Why This Matters for Security Teams

Database and infrastructure access is where standing credentials become operational debt. Shared secrets make it hard to answer a basic question: who actually touched the system, for what reason, and under which approval. That weakens accountability, creates broad blast radius, and encourages password reuse across teams, tools, and environments. Current guidance from the OWASP Non-Human Identity Top 10 and NIST Cybersecurity Framework 2.0 points toward stronger identity-bound access, but many organisations still rely on secrets that outlive the task they were meant to support.

The risk is not theoretical. NHIMG research shows that 62% of all secrets are duplicated and stored in multiple locations, which makes revocation slow and incomplete when a database password or cloud key leaks. The Guide to the Secret Sprawl Challenge shows how sprawl persists even after teams adopt vaults or rotation tooling, because the access model still depends on static credentials rather than session-scoped identity. In practice, many security teams discover this only after a leaked secret has already been reused across environments.

How It Works in Practice

The practical shift is to replace shared secrets with identity-aware brokering. Instead of handing out a database password or SSH key, the team authenticates the requester, validates the business purpose, and issues a short-lived session that is scoped to one target and one action set. That session should be tied to a human identity, an approved change, or a controlled workload identity, with logging that captures the request context.

For infrastructure, that often means using ephemeral certificates, just-in-time privilege elevation, or proxy-based access paths that sit in front of the resource. For databases, it can mean role mapping at connection time, time-bound access tokens, or session recording through a broker rather than direct credential distribution. The security objective is to make access re-evaluated at the moment of use, not granted once and trusted indefinitely. That approach aligns with the broader lifecycle discipline described in NHIMG’s Ultimate Guide to NHIs and Lifecycle Processes for Managing NHIs.

• Use one identity source for authentication, then mint a short-lived session token or certificate for the target system.
• Bind approval to a ticket, incident, or change window so the reason for access is preserved.
• Log session start, command scope, duration, and revocation to support review and rollback.
• Rotate or revoke the underlying secret only if a system still requires one behind the broker.

This model is reinforced by NIST SP 800-53 Rev 5 Security and Privacy Controls, which emphasises access enforcement and auditability at the control layer. These controls tend to break down when legacy applications require long-lived shared passwords embedded in scripts, connection strings, or unmanaged vendor tooling because the broker cannot fully remove direct credential exposure.

Common Variations and Edge Cases

Tighter access control often increases operational overhead, requiring organisations to balance faster incident response against stronger approval and session tracking. That tradeoff becomes more visible in production support, break-glass access, and hybrid environments where not every platform can accept ephemeral identity natively.

There is no universal standard for this yet, but current guidance suggests treating direct shared-secret access as a transition state, not the target. In some environments, a privileged access management layer is still necessary, especially where databases or appliances only support static passwords. In those cases, the broker should become the only place where the secret exists, with automatic checkout limits, recorded sessions, and rapid revocation. The 52 NHI Breaches Analysis and the Top 10 NHI Issues both show that failures usually come from overextended credentials, not from lack of policy language.

For regulated systems, the most durable pattern is to prefer session identity over secret possession and to narrow standing access to the smallest possible break-glass exception. Where toolchains still depend on shared secrets, teams should treat those dependencies as inventory items with owners, expiry dates, and removal plans rather than as permanent architecture.

Related resources from NHI Mgmt Group

• How should security teams handle AI client access to governed data without shared secrets?
• How should security teams secure database access without relying on VPN trust?
• How should security teams govern access risk during ERP modernization without slowing transformation down?
• How should security teams run access reviews for non-human identities?