A certified integration confirms that the connection works to a defined standard, while governed access defines who is accountable for the app’s permissions, lifecycle, and revocation. In practice, certification is a technical assurance, but governance requires ownership, review, logging, and the ability to remove access when the relationship changes.
Why This Matters for Security Teams
The distinction matters because a certified integration can still leave an application with standing access that nobody actively owns. Certification usually answers a narrow technical question: does the connector work as expected, and does it meet a defined standard? Governed access answers the operational question: who is accountable for that access, how is it reviewed, and what happens when the relationship ends. Those are not the same control.
This gap is visible in NHI programs because non-human identities accumulate quickly and often outlast the team that approved them. NHI Mgmt Group notes that only 20% of organisations have formal processes for offboarding and revoking API keys in the Ultimate Guide to NHIs, which is why certification without governance can become a long-lived exposure. The OWASP Non-Human Identity Top 10 also treats over-privilege, weak lifecycle control, and poor visibility as primary risk drivers.
Practitioners should think of certification as evidence of functional trust, while governed access is evidence of accountable trust. In practice, many security teams encounter privilege creep only after an integration vendor changes scope, not during the original approval.
How It Works in Practice
A certified integration is typically granted after a technical review confirms the connection behaves correctly, uses the expected protocol, and conforms to a documented interface or security requirement. That review may include authentication method, data handling, logging, or token exchange. It is useful, but it is usually point-in-time.
Governed access adds the control layer that keeps the integration safe after go-live. Good governance assigns an owner, defines the business purpose, records the exact permissions granted, and ties those permissions to review and revocation workflows. The NIST Cybersecurity Framework 2.0 is helpful here because it treats identity, access, logging, and accountability as ongoing operational functions rather than one-time approvals.
In practice, teams should separate the two questions in their process:
- Certification: does the integration meet the approved technical pattern?
- Governance: who owns the access, what can it do, and when will it be reviewed?
- Lifecycle: how are secrets rotated, access removed, and exceptions tracked?
- Evidence: can the team show logs, approvals, and revocation records on demand?
This is especially important for service accounts, API keys, and automation workflows that continue operating after the original project ends. The Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs makes the lifecycle point clear: permissions must be continuously owned, not merely initially approved. These controls tend to break down when integrations are embedded in CI/CD pipelines because no single team feels responsible for offboarding.
Common Variations and Edge Cases
Tighter certification often increases operational overhead, requiring organisations to balance deployment speed against assurance. That tradeoff becomes sharper when an integration is business-critical, third-party managed, or used across multiple environments.
Current guidance suggests treating “certified” as a minimum quality gate, not a substitute for access governance. A certified integration may still need step-up review if it requests broader scopes, crosses tenant boundaries, or handles sensitive data. Likewise, a governed access model may allow temporary exceptions even when formal certification is pending, but those exceptions should be time-bound and logged.
Edge cases often appear in shared platforms and delegated administration. For example, one application may be technically certified, but the actual non-human identity behind it may be reused by multiple teams, making ownership unclear. In those cases, governance should focus on the identity and its permissions, not just the application wrapper. The Top 10 NHI Issues and the 52 NHI Breaches Analysis both reinforce the same lesson: when ownership is vague, revocation is delayed and exposure persists.
For audit and risk teams, the practical test is simple: certification proves the integration was allowed to connect, but governed access proves someone can still justify that connection today.
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 CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Addresses lifecycle ownership and access sprawl for non-human identities. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions must be managed and reviewed over time. |
| CSA MAESTRO | IAM-02 | Agent and workload access require explicit accountability and lifecycle control. |
Treat certification as an entry control and governed access as an ongoing access review function.
Related resources from NHI Mgmt Group
- What is the difference between reviewing human access and reviewing NHIs?
- What is the difference between role-based access and API key governance for NHI security?
- What is the difference between protecting applications and protecting access?
- What is the difference between attack surface management and NHI governance?
