Akeyless and CyberArk show the cost of fragmented identity control

At a glance

What this is: This comparison argues that secrets, privileged access, and certificate lifecycle management become harder to govern when they are split across separate products.

Why it matters: It matters because IAM, NHI, and PAM teams often inherit fragmented tooling, and the operational gaps between those tools become the real security risk.

👉 Read Akeyless's comparison of secrets, access, and certificate lifecycle control

Context

Identity governance gets harder when secrets, human privileged access, and certificate lifecycle management live in different systems. Each tool may be usable on its own, but the control gaps appear when teams need one policy model, one audit trail, and one revocation path across them.

This article is really about architectural sprawl in identity security, not a single feature comparison. For practitioners, the question is whether the programme is being run as separate products with shared dependencies, or as one lifecycle across machine identity, human access, and certificate management.

Key questions

Q: How should security teams reduce glue work between secrets, PAM, and certificates?

A: They should define one governance boundary for credential issuance, privileged session access, and certificate lifecycle, then remove duplicate workflows that cross tool lines. The goal is not fewer tools for its own sake. It is consistent policy, consistent logging, and consistent revocation across the full identity lifecycle.

Q: Why does fragmented identity tooling increase audit risk?

A: Fragmented tooling forces auditors to reconcile separate logs, approval records, and revocation events across products that do not share the same state. That creates gaps in evidence even when each tool works as designed. A unified audit model makes policy enforcement easier to prove and easier to investigate.

Q: When does just-in-time access still leave standing risk?

A: Just-in-time access still leaves standing risk when the session credential, revocation event, and audit record are not managed in one lifecycle. If the identity state must be pieced together across systems, the organisation has not really removed persistent exposure. It has only redistributed it.

Q: What is the difference between managing certificates separately and managing them as identity assets?

A: Separate certificate management focuses on issuance and renewal as a technical task. Identity-led management treats certificates as part of the same trust boundary as secrets and privileged access, so ownership, revocation, and audit are aligned. That approach is easier to govern and much easier to defend during incidents.

Technical breakdown

Why fragmented secrets and access tooling creates policy drift

When secrets management, privileged access, and certificate lifecycle are split across products, each layer develops its own policy model, approval path, and audit surface. That makes it harder to answer basic governance questions such as who granted access, which credential was issued, and whether the certificate or session was revoked on time. Fragmentation also increases the chance that teams compensate with manual glue, scripts, or duplicate workflows. The result is not just operational overhead. It is a control environment where identity state is no longer consistent across systems.

Practical implication: map every identity-sensitive workflow to a single ownership path so policy and audit state do not diverge across tools.

How just-in-time access changes the human privileged access model

Just-in-time access removes standing privilege by issuing a short-lived credential for a specific session or task. In practice, that shifts privileged access from persistent entitlement to time-bound authorisation, which reduces the chance that stale credentials remain usable after the task ends. The governance challenge is that JIT only helps when session lifecycle, revocation, and logging are tied together. If access, logging, and certificate handling sit in different products, the promised reduction in exposure is weakened by the handoffs between them.

Practical implication: treat JIT as a lifecycle control, not a session feature, and verify that revocation and logging happen in the same control boundary.

Why certificate lifecycle management belongs in the same trust boundary as secrets

Certificate lifecycle management is not just about issuing TLS certificates. It is about ensuring that private keys, issuance policy, renewal, and revocation are governed consistently across the environments that depend on them. When certificates are managed separately from secrets and access, teams often end up with different admin paths, different logging, and different renewal assumptions. That disconnect creates blind spots during audits and response. A single control plane does not eliminate certificate risk, but it makes certificate state visible alongside the rest of identity governance.

Practical implication: align certificate issuance and revocation with the same governance controls used for secrets and privileged access.

NHI Mgmt Group analysis

Identity security fragments when teams bolt together secrets, PAM, and certificate tools. The article illustrates a common enterprise pattern: controls are purchased in layers, then governed as if they were one system. In reality, separate admin layers create separate policy assumptions, which is where drift starts. The implication is that identity governance needs a lifecycle view, not just a product inventory.

One control plane is an operating model, not just a convenience feature. The real issue is not whether one vendor can cover more use cases, but whether the programme can preserve a single source of truth for access, secrets, and certificates. When those states are split, auditability becomes a reconciliation exercise. Practitioners should read this as a warning about governance overhead, not as a feature checklist.

Unified audit trail: The governance value is in correlating secret issuance, access sessions, and certificate actions under one log model. That correlation is what allows responders and auditors to reconstruct identity behaviour without stitching together three different systems. The broader field lesson is that identity evidence matters as much as identity control. Practitioners should measure whether they can prove policy enforcement across the full lifecycle, not just issue credentials.

JIT access only reduces risk when it is tied to revocation, session logging, and certificate state. The article’s model shows that ephemeral access without lifecycle coherence still leaves governance gaps. In practice, the weakest point is usually the handoff between products, where one system grants and another records. Practitioners should treat those handoffs as control boundaries, not implementation details.

From our research:

• 54% of organisations are dissatisfied with their current secrets management solution because not all secrets are secured, and 43% cite lack of central management, according to The 2024 State of Secrets Management Survey.
• Only 44% of organisations are currently using a dedicated secrets management system, which helps explain why fragmented identity control remains common in practice.
• For the broader lifecycle view, see Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs, where governance, rotation, and offboarding are treated as one discipline.

What this signals

Identity control is converging around lifecycle management, not point solutions. The practical signal for security teams is that secrets, privileged access, and certificate governance will keep collapsing into the same operating model. Where those functions remain split, the programme inherits more reconciliation work, more audit friction, and more opportunities for drift. Teams should expect reviewers to ask not just whether access exists, but whether the full chain is governable in one place.

Unified auditability will become the differentiator that matters most. A control plane that can correlate issuance, access, and revocation is easier to defend than a collection of tools with overlapping claims. That is especially true for teams mapping identity programmes to NIST Cybersecurity Framework 2.0 outcomes around access control, detection, and recovery. Practitioners should prepare for more scrutiny on evidence quality, not just capability coverage.

For practitioners

• Map identity control boundaries Document where secrets, privileged access, and certificate lifecycle are governed today, then identify where policy, logging, and revocation change hands between products. Those handoffs are the places where drift and blind spots emerge.
• Collapse duplicate approval paths Remove separate approval flows for application secrets, human access, and certificate issuance where they create inconsistent entitlement records. A single policy boundary is easier to audit than three partial ones.
• Validate revocation across all three layers Test whether revoking a secret, ending a remote session, and removing a certificate attachment all produce immediate and traceable state changes in the same audit trail. If they do not, the control model is fragmented.
• Review certificate ownership with the same discipline as PAM Assign clear operational owners for certificate issuance, renewal, and revocation, then align those responsibilities with privileged access governance. Certificates are identity assets, not background plumbing.

Key takeaways

• Fragmented secrets, access, and certificate tooling turns identity governance into reconciliation work.
• The core risk is not product count alone, but the policy and audit drift created at the handoffs between tools.
• Practitioners should evaluate whether their identity programme can prove revocation, access, and certificate state within one lifecycle.

Key terms

• Control Plane: A control plane is the layer that sets policy, issues credentials, and records identity actions across a system. In identity security, it matters because governance breaks down when access, secrets, and certificates are managed in different places with different audit states.
• Just-in-Time Access: Just-in-time access is a short-lived privilege model that grants access only for a specific session or task. For identity programmes, it reduces standing privilege, but only when granting, logging, and revocation are managed as one lifecycle rather than separate tool events.
• Certificate Lifecycle Management: Certificate lifecycle management covers issuance, renewal, deployment, and revocation of certificates that secure system and workload communications. It is an identity discipline because certificates represent trust, and trust becomes harder to govern when certificate state is disconnected from secrets and access controls.
• Unified Audit Trail: A unified audit trail brings credential issuance, access sessions, and certificate actions into one evidence stream. That makes it possible to prove policy enforcement without stitching together logs from multiple tools, which is often where identity investigations lose time and confidence.

What's in the full article

Akeyless's full post covers the operational detail this analysis intentionally leaves for the source:

• Step-by-step walkthrough of dynamic secret issuance for PostgreSQL workloads and the API flow behind it.
• Certificate chain creation and attachment steps for provisioning TLS material onto a target machine.
• Secure Remote Access session flow for human DBA access without shared SSH keys or VPN dependency.
• Unified audit trail examples showing secret requests, certificate issuance, and remote session records in one console.

👉 The full Akeyless post shows the workflow details behind dynamic secrets, PKI chain creation, and secure remote access.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or identity governance in your organisation, it is worth exploring.