Who is accountable when a certified IAM platform is misused or misconfigured?

Why This Matters for Security Teams

Certification can be useful, but it is not a transfer of accountability. When a platform is certified, that usually means a defined product, release, or control set was assessed against a framework. It does not mean the buying organisation has configured it safely, limited privileged access, or monitored how it is actually used. NIST’s SP 800-53 Rev 5 Security and Privacy Controls still places responsibility on the system owner to implement and operate controls effectively.

That distinction matters because NHI and IAM failures usually happen in deployment, not in the sales process. NHIMG’s Ultimate Guide to NHIs — What are Non-Human Identities notes that 97% of NHIs carry excessive privileges, which is exactly the kind of condition that certification cannot prevent on its own. In practice, misconfiguration, role sprawl, and weak evidence collection become the real control gaps. In practice, many security teams encounter the failure only after a privileged path is abused or audit evidence cannot be produced, rather than through intentional governance.

How It Works in Practice

Accountability sits with the organisation that operates the platform, even when the vendor has completed certification. That means security, IAM, cloud, and application owners must define who approves access, who reviews policy changes, who manages break-glass accounts, and who verifies that logs, alerts, and retention settings actually work. Certification may support procurement due diligence, but operational control still depends on the buyer’s configuration and oversight.

For most teams, the practical model is to treat the platform as one control layer inside a wider governance chain. The platform may provide role templates, policy engines, secrets storage, or privileged session recording, but the organisation still needs:

• clear ownership for tenant, connector, and policy configuration
• restricted administrative access to the IAM platform itself
• continuous review of privileged assignments and exceptions
• evidence that logs, alerts, and audit trails are complete and retained
• third-party risk review for integrations, support access, and delegated administration

That operating model aligns with NHIMG guidance in the Ultimate Guide to NHIs — The NHI Market, which shows how commonly NHIs are overexposed and overprivileged across modern environments. It also lines up with security practice described in NIST control families around access control, audit, and configuration management. If the platform is used for secrets, the organisation should also expect the same discipline around rotation, revocation, and storage locations that it would apply to any other sensitive credential path.

Teams often get this wrong by assuming the certification badge covers local policy design. These controls tend to break down when the platform is integrated into hybrid estates with multiple admins, delegated support, and inconsistent change control, because responsibility fragments across too many operators.

Common Variations and Edge Cases

Tighter certification claims often increase procurement confidence, but they also create a false sense of closure, so organisations must balance vendor assurance against their own control testing. Current guidance suggests the accountability question changes with deployment model, not with the certificate. A hosted SaaS IAM platform, an on-prem appliance, and a federated identity broker all shift operational tasks differently, but none removes the buyer’s duty to govern use.

There is no universal standard for this yet, but good practice is to document which party owns configuration, incident response, patching, support access, and evidence production. That is especially important where the platform touches privileged access, secrets, or third-party integrations. NHIMG’s reporting on the Azure Key Vault privilege escalation exposure is a useful reminder that a technically sound product can still be misused through excessive permissions.

In regulated environments, the answer is usually even stricter: certification may reduce diligence burden, but it rarely changes legal or contractual accountability for misuse. The organisation should retain evidence of acceptance, periodic review, and compensating controls, especially where a supplier has administrative reach or can influence policy updates. If the platform is connected to critical workflows, the question is not whether it was certified, but whether the organisation can prove who owned the risk when it failed.

Related resources from NHI Mgmt Group

• What is the difference between human IAM controls and NHI governance?
• What does the 144:1 NHI-to-human ratio mean for IAM governance programmes?
• Where does cross-environment agent discovery fit in an IAM programme?
• When should organizations consider updating their IAM frameworks?