What breaks when an IGA platform treats flat file uploads as connected apps?

Why This Matters for Security Teams

Flat file uploads are tempting because they are easy to automate, but they are not a connected system of record. When an IGA platform accepts a CSV as if it were a live application integration, it can only certify what someone exported at a point in time. That breaks completeness, freshness, and traceability, which are all core to governance. The result is a control that looks precise while missing the very accounts that create most risk, especially orphaned service accounts, shared admin accounts, and high-privilege entitlements.

This is not a minor data quality issue. It changes the assurance model. A connected app can support reconciliation, change detection, and defensible recertification; a flat file cannot prove what changed after export, whether the feed was partial, or whether the source system had already drifted. NHI Mgmt Group’s Ultimate Guide to NHIs — The NHI Market notes that only 5.7% of organisations have full visibility into their service accounts, which is why these false integrations are so dangerous. In practice, many security teams discover the gap only after an access review has already been signed off on stale data.

How It Works in Practice

In an IGA workflow, a real connected app typically authenticates to the target system, queries current entitlements, and supports ongoing reconciliation. That means the platform can compare current state against previous state, flag drift, and verify who still has access. A flat file upload bypasses that model entirely. It is just an imported snapshot, so the platform has no native way to confirm whether the export was complete, whether privileged roles were omitted, or whether the file reflects the source system at the time of certification.

That distinction matters for recertification, joiner-mover-leaver processes, and orphan cleanup. If the platform treats CSV rows as authoritative account objects, reviewers may approve stale or partial records and mistake formatting for evidence. Current guidance from NIST Cybersecurity Framework 2.0 emphasizes repeatable governance and verification, but a file import cannot give you continuous confidence by itself. For NHI-heavy environments, the better pattern is to treat file uploads as supplemental evidence only, then back them with direct system queries, scheduled reconciliation, and strong ownership metadata. NHI Mgmt Group’s research on the Ultimate Guide to NHIs — The NHI Market is especially relevant here because the control failure is usually not the review itself, but the missing visibility upstream.

• Use CSVs for exception handling, not as the primary identity source.
• Require source-system ownership, timestamps, and extraction scope for every upload.
• Reconcile imported data against live entitlements before certification begins.
• Keep service accounts, APIs, and privileged roles on direct connectors whenever possible.

These controls tend to break down when the source is a legacy application, a mainframe, or a manually maintained admin registry because the organisation cannot verify completeness at ingest.

Common Variations and Edge Cases

Tighter governance often increases operational overhead, requiring organisations to balance coverage against integration cost and system complexity. That tradeoff is real in legacy estates, where a flat file may be the only practical way to inventory accounts temporarily. Current guidance suggests treating those uploads as a compensating control, not as equivalent to a connected application, because the risk of false assurance remains high.

One common edge case is a hybrid model where a file upload seeds the initial inventory and a later connector validates it. That can work, but only if the platform clearly separates “discovered from file” from “verified by live query.” Another edge case is a third-party system that can only export on a schedule; in that case, reviewers should assume data is stale unless the export cadence and scope are documented and monitored. The NHI problem is often worse than teams expect, and Ultimate Guide to NHIs — The NHI Market helps explain why snapshot-based governance misses service-account sprawl. Best practice is evolving, but there is no universal standard that says a flat file alone equals a connected application. Security teams should validate whether the platform is certifying records or actually governing identities before they rely on the result.

Related resources from NHI Mgmt Group

• What breaks when IGA is not tightly connected to IAM?
• What breaks when deprovisioning does not reach connected apps?
• What breaks when an IGA platform cannot reissue entitlements during role changes?
• How should security teams govern SaaS apps that are discovered but not connected to IGA?