TL;DR: Identity governance platforms often count manual CSV uploads as connected apps, but those flat files are stale, incomplete, and hard to audit, creating false coverage and retained access risk according to Cerby. The governance problem is not connector coverage alone, but whether access data can be verified continuously rather than borrowed from a point-in-time export.
At a glance
What this is: This analysis says flat file feeds are not true app connections, and that treating them as connected creates false coverage, stale access data, and audit risk.
Why it matters: IGA teams need to distinguish verification from reporting because access reviews, certifications, and audit evidence are only as credible as the underlying data path.
Context
Identity governance depends on whether the platform is reading live system state or a copied export. When an application is covered by a flat file, the governance record reflects what someone chose to extract at a point in time, not what actually exists in the source system.
That matters for IGA because certification, audit, and risk decisions inherit the weaknesses of the feed. If the export is incomplete or stale, the programme can report coverage without being able to verify access, which creates false confidence in governance outcomes.
Key questions
Q: What breaks when an IGA platform treats flat file uploads as connected apps?
A: The platform loses verification. A CSV only reflects what was exported, not what exists in the source system, so completeness, freshness, and auditability all weaken at once. That creates false confidence in certification results and can leave orphan accounts, service accounts, and privileged entitlements outside governance.
Q: Why does stale access create audit and compliance risk for regulated data?
A: Stale access matters because permissions often outlive the project, role, or employee that justified them. When access remains broader than required, auditors may view it as a least-privilege failure, and investigators lose confidence in who could reach sensitive records. That weakens HIPAA, PCI, and GDPR evidence and increases the chance of unauthorized disclosure going undetected.
Q: How should teams decide which apps can stay on flat files temporarily?
A: Use flat files only as a short-term exception for low-risk systems with minimal entitlement complexity and no privileged scope. If the app drives certifications, regulatory evidence, or sensitive access decisions, it should move to direct synchronization or it will keep producing weak assurance.
Q: What is the difference between connected coverage and verified coverage in IGA?
A: Connected coverage means the platform has ingested some access data for the app. Verified coverage means the platform is reading current source-system state in a way that can support review, remediation, and audit without relying on a manually handled export.
Technical breakdown
Why flat file feeds are not live connections
A flat file is a copy of access data, not a direct read from the application. That means the export only contains what the report was built to collect, and anything outside that query path is invisible to the governance platform. In complex systems, that can include orphan accounts, service accounts, privileged users, or data stored in tables the export never touched. The result is a governance record that looks populated but is structurally incomplete.
Practical implication: Treat CSV ingestion as a data workaround, not as evidence that the application is actually governed.
How stale exports distort access review and certification
Most flat file processes run on long intervals, so the governance platform is often reviewing access data that is months old. That creates a time gap between the current state of access and the state that the review is certifying. Delta files reduce transfer size, but they do not fix the core problem because they still represent a copy, not a live synchronisation. Without a closed loop back to the source system, the platform cannot confirm whether a removal or change actually landed.
Practical implication: Base certification decisions on scheduled synchronisation from the source system, not on periodic extracts.
Why auditors focus on apps governed through spreadsheets
Auditors tend to probe the weakest evidence path first, and flat files are weak because they are editable before ingestion and often unsupported by system-generated proof. That pushes reviewers to ask for reconstructed approvals, especially around privileged or in-scope access. The issue is not only extra audit effort. It is that the organisation cannot defend its claim of connected coverage when the underlying evidence is a manually handled file rather than a system of record.
Practical implication: Prioritise replacing spreadsheet-based governance feeds in systems that carry audit scope or privileged access.
Breaches seen in the wild
- Microsoft SAS token exposure 2023: An over-permissive Azure SAS token in a Microsoft AI GitHub repo exposed 38TB, including workstation backups and Teams messages, for 3 years.
- Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
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
Flat file governance creates an identity assurance gap, not just a coverage gap. The problem is not that the platform is missing a connector in the abstract. The problem is that governance is being asserted over data that was copied, scoped, and handled outside the source of truth. That breaks the credibility of access reviews, certifications, and audit reporting because the platform cannot prove what it cannot continuously read.
Flat file coverage is a false control boundary. Teams often treat a CSV feed as temporary coverage until a connector exists, but the control outcome is different from a live integration. A copied export can never show the full entitlement surface, and it cannot confirm remediation back in the source system. Practitioners should stop describing these feeds as connected apps and treat them as unverified evidence streams.
Continuous verification, not app counting, is the governance standard that matters. The article shows how easily dashboards can overstate control maturity when coverage is measured by ingestion rather than by source-system reach. The practical implication is that identity programmes must measure whether access data is verifiable at the source, not whether it is present in the IGA repository.
Flat file governance is a lifecycle problem as much as a connector problem. The gap appears at collection, persists through certification, and becomes hardest to defend at audit time. That means NHI-style lifecycle thinking applies here even in human IAM because the evidence itself has to be onboarded, refreshed, and offboarded as part of governance. Teams need to think in terms of evidence lifecycle, not just application onboarding.
Flat file governance exposes a credentialed trust assumption inside IGA. The assumption that a scheduled export is sufficiently faithful to the live system was designed for slower application change and lower audit pressure. That assumption fails when app portfolios outgrow connector catalogs and access changes faster than review cycles. The implication is that governance programmes must rethink what counts as authoritative evidence, not simply add more spreadsheet reviews.
What this signals
Flat file governance is an evidence-quality problem disguised as connector coverage. Identity programmes that rely on spreadsheets are not just under-integrated, they are governing on copied data that may already be obsolete when it enters the platform. That shifts the real control question from coverage counts to whether the source system is continuously verifiable.
App portfolios will keep outrunning connector catalogs, so governance teams need a stronger evidence model. The operational decision is no longer whether a file can be ingested, but whether the resulting record is authoritative enough for certification, audit, and remediation. In practice, that means prioritising direct system reads for the systems that carry the most risk and the most scrutiny.
For practitioners
- Replace flat file coverage with source-system connectors Prioritise direct connectors for applications where access, entitlements, or audit evidence matter, so the governance platform reads the current system state instead of a manually exported copy.
- Reclassify CSV feeds as unverified evidence Stop counting manual uploads as connected apps in dashboards and audit reports, and label them separately so reviewers understand they are point-in-time extracts with limited assurance.
- Target the highest-risk flat file apps first Start with applications that contain privileged access, large entitlement sets, or audit scope, because those are the cases most likely to hide missing accounts and incomplete approval trails.
- Validate closed-loop remediation Check whether the governance process can both flag removals and confirm that the source system actually changed, because a one-way file feed cannot prove enforcement.
Key takeaways
- Flat file governance weakens identity assurance because the platform is certifying copied data, not authoritative source-system state.
- When access reviews run on stale exports, the organisation inherits false coverage and cannot reliably prove remediation.
- The practical fix is to reserve flat files for short-lived exceptions and move sensitive or audit-scoped applications to direct synchronization.
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 addresses the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about whether entitlement data used for governance is authoritative and current. |
| Recommendation — Apply PR.AA-05 to verify that entitlement records come from current source-system data. | ||
| CIS Controls v8 | CIS-5 — Account Management | Flat file governance obscures account completeness and lifecycle accuracy. |
| Recommendation — Use CIS-5 to reconcile governed accounts against the live source system, not a copied export. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article highlights stale governance data around accounts and access changes. |
| Recommendation — Use IA-5 to tie credential and account lifecycle evidence back to authoritative system records. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Stale flat files can leave retained access invisible to governance processes. |
| NHI-07 — Long-Lived Secrets | Manual exports extend the life of stale access evidence beyond its useful assurance window. | |
| Recommendation — Audit offboarding coverage where exported access data can mask lingering accounts. Replace long-lived exported access files with continuously refreshed identity data. | ||
Key terms
- Flat File Governance: A governance model that relies on exported reports, usually CSV files, instead of live system connections. It can provide a partial view of access, but it cannot prove completeness or freshness without additional controls, which makes it weaker for certification and audit evidence.
- Verified Coverage: Coverage that can be proven from a live or continuously synchronised source rather than assumed from an uploaded file. For identity teams, verified coverage means the control can show current accounts, entitlements, and change state at the point of decision, not only at export time.
- Closed-Loop Remediation: A governance process that does not stop at finding risk. It removes or reduces access, confirms the change in the source systems, and keeps evidence that the risky condition stayed fixed. For NHIs, this is the difference between inventory and actual risk reduction.
- Evidence lifecycle management: The discipline of creating, retaining, searching, and validating proof across its full useful life. In AppSec, that means keeping findings, remediation records, policy versions, and approvals attached to releases so auditors can verify what happened without reconstruction.
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.
Published by the NHIMG editorial team on July 30, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org