Notifications
Clear all
Topic starter
10/06/2026 12:20 am
TL;DR: Traditional IAM automation works best where APIs and connectors exist, but non-integrated portals, vendor-managed systems, and legacy UI applications still create execution gaps that turn policy into manual work, brittle RPA, and audit risk, according to Opnova. Governance strength now depends on whether controls can execute consistently across the full identity surface, not just the integrated half.
NHIMG editorial — based on content published by Opnova: Extending Identity Governance Beyond Integrated Systems
Questions worth separating out
Q: How should security teams govern applications that do not support APIs or SCIM?
A: Security teams should classify non-integrated applications as a distinct execution tier and design governance around the controls those systems can actually support.
Q: Why do disconnected systems create IAM risk even when policies are well defined?
A: Disconnected systems create risk because policy without execution is only intent.
Q: What do teams get wrong about RPA in identity governance?
A: Teams often treat RPA as a substitute for integration, but it is really a workaround with fragility built in.
Practitioner guidance
- Inventory execution paths, not just applications. Separate API-connected systems, UI-only systems, and vendor-managed portals into distinct governance classes so you can see where policy can be enforced natively and where it cannot.
- Document the control evidence for each non-integrated workflow. Require proof of completion, exception handling, and revocation for tickets, manual actions, and RPA-driven tasks so audit teams can verify what actually happened.
- Treat offboarding in disconnected systems as a containment exercise. Prioritise revocation and access removal in regulatory portals, legacy applications, and external platforms where the identity lifecycle is hardest to execute end to end.
What's in the full article
Opnova's full blog covers the operational detail this post intentionally leaves for the source:
- The automation coverage matrix that separates integrated, non-integrated, and hybrid execution paths.
- The practical examples of regulatory portals, legacy UI systems, and vendor-managed applications without API or SCIM access.
- The operational framing for how AI agents and deterministic guardrails interact in disconnected environments.
- The article's lifecycle-alignment discussion for access changes, offboarding, and cross-system reconciliation.
👉 Read Opnova's analysis of extending IAM beyond APIs →
Non-integrated systems and IAM: where does governance break down?
Explore further
11/06/2026 2:05 am
Non-integrated execution is the real IAM control boundary. IAM programmes were built to govern systems that expose structured interfaces, and that assumption no longer matches the enterprise. When policy intent reaches a UI-only or vendor-managed environment, the control no longer acts directly and governance turns into approximation. The implication is that architecture reviews must stop treating integration as an implementation detail and start treating it as the condition that determines whether governance is real.
A few things that frame the scale:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
- That same research shows only 5.7% of organisations have full visibility into their service accounts, which is why execution gaps and visibility gaps usually travel together.
A question worth separating out:
Q: What should organisations do first to close identity execution gaps?
A: Start by mapping where identity decisions actually fail to reach the target system, then prioritise the highest-risk workflows such as offboarding, role changes, and regulatory access. The goal is to align policy, execution, and evidence across the full identity lifecycle, especially where external portals and legacy UI systems are involved.
👉 Read our full editorial: Extending IAM beyond APIs exposes the enterprise execution gap
12/06/2026 3:39 am
Non-integrated execution is the real IAM control boundary. IAM programmes were built to govern systems that expose structured interfaces, and that assumption no longer matches the enterprise. When policy intent reaches a UI-only or vendor-managed environment, the control no longer acts directly and governance turns into approximation. The implication is that architecture reviews must stop treating integration as an implementation detail and start treating it as the condition that determines whether governance is real.
A few things that frame the scale:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
- That same research shows only 5.7% of organisations have full visibility into their service accounts, which is why execution gaps and visibility gaps usually travel together.
A question worth separating out:
Q: What should organisations do first to close identity execution gaps?
A: Start by mapping where identity decisions actually fail to reach the target system, then prioritise the highest-risk workflows such as offboarding, role changes, and regulatory access. The goal is to align policy, execution, and evidence across the full identity lifecycle, especially where external portals and legacy UI systems are involved.
👉 Read our full editorial: Extending IAM beyond APIs exposes the enterprise execution gap
