Replacing IGA with Microsoft workflows exposes governance gaps in higher ed

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Fischer Identity's blog post: Replacing dedicated IGA with Microsoft workflows in higher education is a cautionary move because automation alone does not deliver governance.

Why it matters: It matters because IAM and IGA teams in higher education need auditability, lifecycle modelling, and policy enforcement across complex affiliations, not just scripted task automation.

Context

Higher education identity governance fails when institutions assume that automating tasks is the same as governing access. Microsoft workflows can move people through onboarding and offboarding, but they do not natively provide the policy depth needed for role modelling, segregation of duties, access certification, or lifecycle state control across complex campus identities.

That distinction matters because universities rarely operate a simple employee lifecycle. Students, staff, faculty, researchers, alumni, and clinical roles often overlap across ERP, SIS, HR, research, and departmental systems, so any approach that flattens identity into workflow steps quickly loses the governance structure needed for auditability and risk control.

Key questions

Q: What breaks when higher education replaces IGA with Microsoft workflows?

A: The institution often loses role modelling, SoD enforcement, certification discipline, and a stable evidence trail. Workflows can still move accounts through events, but they do not by themselves preserve the governance structure needed to explain why access exists or whether it remains appropriate.

Q: Why do Microsoft workflows create audit risk in identity governance?

A: Because audit evidence becomes distributed across scripts, approvals, logs, and undocumented business rules instead of a central governance record. Auditors then have to reconstruct decisions after the fact, which is slower, weaker, and more fragile than a controlled certification process.

Q: How do security teams decide when workflow automation is not enough for IGA?

A: If the programme needs policy enforcement, recurring access review, SoD controls, and lifecycle modelling across multiple systems, workflow automation is not enough. Those are governance functions, not just process steps, and they need a platform that keeps identity state and evidence together.

Q: What is the difference between workflow automation and autonomous identity governance?

A: Workflow automation follows predefined steps and approval gates, so it still fits a conventional governance model. Autonomous identity governance is different because the actor can choose actions and timing at runtime. That changes the control problem from approving a process to governing an independent decision-maker, which requires a much tighter runtime view of access and behaviour.

Technical breakdown

Why workflow automation is not identity governance

Workflow automation executes tasks such as group updates, account disablement, and notifications. Identity governance, by contrast, governs the policy and control layer that decides whether access should exist, how it is reviewed, and how exceptions are evidenced. In this article’s context, Microsoft workflows can orchestrate actions, but they do not inherently model entitlements, enforce SoD rules, or preserve audit-ready decision records. When those controls are embedded in scripts and flow diagrams, governance becomes distributed across code and people instead of living in a managed identity control plane.

Practical implication: Treat workflow tooling as orchestration infrastructure, not as a substitute for governance control design.

Why higher education identity states are harder to automate safely

Higher education identity is dynamic and multi-affiliate. A single person may be a student, employee, researcher, and alumni account holder across different systems and policy states. That creates a lifecycle modelling problem, not just an automation problem. Without a platform that understands identity state over time, a workflow can process a change event but still miss the entitlement context attached to that identity. The result is access drift, unmanaged exceptions, and policy decisions that cannot be reproduced cleanly during audit or incident review.

Practical implication: Model affiliations, lifecycle states, and policy conditions explicitly before deciding what can be safely automated.

How custom identity logic creates audit and resilience debt

When identity logic is scattered across API calls, scripts, and approval flows, the institution inherits custom-code governance debt. The process may function on day one, but later troubleshooting depends on developer memory, undocumented dependencies, and brittle maintenance after staff turnover or platform updates. That is especially problematic in regulated higher education environments where auditors ask not only whether access changed, but why it changed and whether policy approved it. A workflow can show that something happened; governance must show why it was allowed.

Practical implication: Centralise entitlement logic and approval evidence so access decisions remain explainable after personnel and platform changes.

Breaches seen in the wild

• tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Automation without governance is structural regression, not simplification. Replacing an IGA platform with Microsoft workflows changes the control model from policy-centric governance to task-centric orchestration. That may reduce surface complexity, but it also removes the durable structure needed for role engineering, certification, and entitlement traceability. In higher education, where the same person can hold multiple affiliations and access states, that shift weakens institutional control rather than modernising it. Practitioners should treat this as a governance architecture decision, not a tooling preference.

Higher education exposes the limits of script-based identity control. Campus environments combine ERP, SIS, research, clinical, and departmental systems, so identity logic has to survive change, turnover, and policy review. When that logic is encoded in workflows and developer-owned scripts, the institution creates tribal-knowledge risk and makes audit reconstruction harder than it should be. The named concept here is governance by custom code: once identity control becomes implementation detail, continuity and accountability depend on whoever last touched the script. That is a fragile operating model for regulated institutions.

Access certification and SoD cannot be treated as workflow side effects. Those controls exist to test whether access still matches policy, whether conflicting entitlements have been granted, and whether decisions can be defended later. A workflow can trigger an approval, but it does not automatically create a governable certification programme or a durable SoD model. The control gap is not missing automation; it is missing governance intent. Practitioners should recognise that some controls must remain explicit, central, and reviewable rather than embedded in ad hoc orchestration.

Microsoft-native tooling is strongest inside Microsoft boundaries, not as a universal identity control plane. The article’s real warning is about scope, not capability. Once identity orchestration extends into mixed higher education estates, the institution has to manage heterogenous systems, lifecycle complexity, and evidence retention across more than one operating model. That is where dedicated IGA retains value: it institutionalises identity policy rather than personalising it in local scripts. Teams should evaluate whether their design is still a governance programme or whether it has become a collection of clever automations.

The relevant decision is whether the institution wants configurable governance or recoverable automation. Workflow tools can execute a business process, but governance requires policy memory, review discipline, and evidence continuity. In practice, the question is not whether Microsoft can automate identity actions, but whether the institution can still explain, certify, and audit them six months later. That distinction should drive architecture choices in higher education identity programmes.

From our research library:

• Nearly 60% of IT leaders cite restrictive cost and complexity as a weakness of legacy identity governance, according to the 2025 State of Identity Governance Report.
• Read next: Access Reviews and Certification Guide

What this signals

Governance by custom code: once identity policy is dispersed into scripts and workflow branches, institutions inherit maintenance debt that survives staff turnover and platform changes. That creates a gap between what the workflow can execute and what the institution can still prove later.

Higher education teams should test whether their identity programme can still produce certification evidence, SoD reasoning, and lifecycle history without relying on developer recall. If not, the operating model has already shifted from governed identity management to recoverable automation.

Microsoft-native automation can support orchestration, but campus identity programmes need an explicit governance layer that survives mixed affiliations, non-Microsoft systems, and audit scrutiny.

For practitioners

• Separate orchestration from governance Use Microsoft workflows for task execution only, and keep role modelling, SoD policy, certification, and entitlement evidence in a governed identity platform.
• Map identity states across campus populations Document how applicants, students, employees, alumni, adjuncts, researchers, and clinical staff move through identity states before replacing any lifecycle controls.
• Preserve audit-ready access evidence Ensure every access grant, approval, exception, and review can be reconstructed without relying on script history, email chains, or developer memory.
• Limit custom logic in access decisions Avoid embedding policy decisions in dispersed API calls and workflow branches where they become difficult to maintain, test, and certify.

Key takeaways

• Replacing IGA with Microsoft workflows can improve task automation, but it weakens governance when policy enforcement, certification, and role modelling are no longer central.
• Higher education magnifies the risk because identity state changes across students, staff, faculty, alumni, researchers, and clinical roles are too complex for simple event-driven automation.
• The practical test is whether the institution can still explain, certify, and defend access decisions after the script author is gone and the audit begins.

Key terms

• Identity Governance: Identity governance is the set of controls that defines who approves access, who owns it, how it is reviewed, and when it is removed. In practice, it turns identity management from a deployment task into a durable control system that can withstand audits, organisational change, and operational growth.
• Runtime Orchestration: Runtime orchestration is the process of deciding which agent runs next, what it should do, and when the workflow stops. In agentic systems, this can be handled by an LLM, but that makes the orchestration layer part of the security boundary and not just application logic.
• Segregation of Duties: Segregation of Duties is a control principle that prevents one person or role from combining incompatible permissions that could create fraud, error, or undetected change. In ERP environments, it must account for roles, transactions, approvals, and compensating controls across business processes.
• Access Certification: Access certification is the periodic review of whether an identity still needs its current entitlements. For NHIs, certification is only reliable when reviewers know the identity's owner, purpose, and expiry, otherwise stale machine access can persist long after the original use case has ended.

Deepen your knowledge

NHI governance, identity lifecycle management, and workload identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.