Notifications
Clear all
Topic starter
25/06/2026 1:28 am
TL;DR: Integration and implementation remain the biggest barrier to security maturity, as technology partners need direct access to a platform to build certified, more deeply integrated apps rather than basic connectors, according to SailPoint. The implication is that identity teams must treat partner ecosystems as part of the governance surface, not just an integration layer.
NHIMG editorial — what this means for NHI practitioners
Questions worth separating out
Q: How should security teams govern partner-built identity applications?
A: Security teams should treat partner-built identity applications as governed extensions of the control plane, not as simple connectors.
Q: Why do partner ecosystems create more identity governance risk?
A: Partner ecosystems create more risk because each new extension introduces a new authority path inside the identity programme.
Q: When should organisations recertify third-party identity applications?
A: Organisations should recertify third-party identity applications whenever access scope, data scope, or ownership changes, and after any partner relationship update that affects trust.
Practitioner guidance
- Define partner app trust tiers Classify every partner-built application by the identity data it can access, the workflows it can trigger, and whether it can change policy outcomes.
- Add offboarding controls for ecosystem apps Require a revocation path for partner applications that mirrors service-account offboarding, including access removal, token invalidation, and ownership reassignment when the commercial relationship ends.
- Expand recertification beyond accounts Include partner-built applications in access reviews so governance teams validate not only who has access, but which external extensions still have delegated authority inside the platform.
What's in the full announcement
SailPoint's full article covers the operational detail this post intentionally leaves for the source:
- How the partner membership and shared-success model is structured for ecosystem participants
- What certified integrations mean for technology partners building native applications on the platform
- Which inaugural partners are already participating in the program
- How SailPoint describes the commercial and technical path from basic integrations to native apps
👉 Read SailPoint's announcement on Unified Platform Access for technology partners →
Unified platform access for identity partners: what changes now?
Explore further
25/06/2026 10:54 am
Unified platform access shifts the governance problem from integration to delegated authority. The article is not really about connectors, it is about allowing external partners to build directly against the identity platform's operating surface. That means the security question moves from whether data can move between systems to who can shape identity outcomes inside the platform. Practitioners should treat this as an extension of the governance plane, not a convenience feature.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to GitGuardian & CyberArk.
A question worth separating out:
Q: What is the difference between a certified integration and governed access?
A: 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.
👉 Read our full editorial: Unified platform access changes identity partner governance
