The most common mistake is treating certification as a universal security guarantee. In practice, it only covers a defined product scope and configuration. Teams still have to manage configuration drift, patch cadence, secrets exposure, and the lifecycle of identities that run on top of the platform.
Why This Matters for Security Teams
Platform certification is often misunderstood as proof that a service is secure in all conditions, but certification usually only validates a specific scope, version, and control baseline. That matters because attackers and outages rarely stay inside the brochure version of a platform. Once configuration changes, integrations, secrets handling, or delegated identities are added, the assurance boundary shifts. NHI Management Group’s Ultimate Guide to NHIs — What are Non-Human Identities shows why this is especially dangerous for service accounts and API keys, which are often outside the original certification assumptions.
The other common error is assuming certification replaces ongoing governance. It does not tell a team whether secrets are rotated, whether offboarding works, or whether privilege has drifted over time. Current guidance from the NIST Cybersecurity Framework 2.0 still places responsibility on the organisation to manage risk continuously, not at point of purchase. In practice, many security teams discover the gap only after an audit exception, a leaked credential, or a third-party integration has already expanded access beyond the certified design.
How It Works in Practice
Operationally, certification should be treated as an input to due diligence, not a substitute for internal control design. Teams need to separate what the certificate actually covers from what their deployment introduces. That means checking the certified boundary, reviewing the security assumptions, and mapping the platform to the identities, secrets, and automations that will run on top of it. The NHIMG Sisense breach is a useful reminder that downstream identity exposure can create risk even when the underlying platform is marketed as trusted.
Practitioners should validate at least four areas:
- scope and version, including what modules, regions, or deployment modes were actually assessed
- identity and access, especially service accounts, API keys, federated access, and admin roles
- secrets management, including where credentials are stored, rotated, and revoked
- change control, so drift from the certified baseline is detected quickly
Certification also has to be paired with monitoring. Logging, configuration review, and privilege analytics help detect when a certified product is being used in an uncertified way. For AI-enabled platforms, this becomes more complex because tool access, prompt handling, and model integrations can introduce new paths for misuse. In those environments, current guidance suggests aligning platform assurance with the AI system lifecycle, not just the infrastructure layer, and using the Ultimate Guide to NHIs — The NHI Market to frame the operational identity risks that often sit outside certification language. These controls tend to break down when procurement assumes the certificate covers custom integrations, because the real exposure is usually created after deployment.
Common Variations and Edge Cases
Tighter certification requirements often increase procurement time and operational overhead, requiring organisations to balance assurance against delivery speed. That tradeoff becomes sharper in cloud, SaaS, and AI platforms where the product is continuously changing and the customer controls only part of the stack. In those cases, there is no universal standard for how much reliance a team should place on a certificate alone; best practice is evolving toward continuous validation rather than one-time trust.
One edge case is shared responsibility confusion. A vendor certificate may cover infrastructure controls, while the customer still owns access policy, data handling, and incident response. Another is inherited trust across suppliers: if a certified platform connects to uncatalogued integrations or external automation, the effective risk profile changes even though the certificate remains valid. That is where identity becomes central, because non-human identities often outlive the control review that approved the platform in the first place.
Security teams should therefore use certification as a starting point for control mapping, not as the end state. The practical question is not “Is it certified?” but “What exactly is certified, what changed since then, and which identities now depend on it?”
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OV-01 | Certification must be checked against real operational risk and system scope. |
| OWASP Non-Human Identity Top 10 | Certified platforms still fail when non-human identities and secrets are unmanaged. | |
| NIST AI RMF | GOVERN | AI-enabled platforms need ongoing governance beyond static assurance claims. |
| OWASP Agentic AI Top 10 | TBD | Agentic tools and automations can expand risk beyond the certified product scope. |
Inventory, rotate, and revoke machine identities that sit outside the certification boundary.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
