Shadow IT in low-code: when unauthorized apps break security

It is the small internal tool built for a narrow operational problem, connected to a sensitive data source, and then forgotten when its creator changes roles.

That tool may begin as a form for vendor onboarding, a dashboard for customer escalations, or an approval workflow for employee requests. It may never pass through procurement, architecture review, or application security testing. Yet it can still process customer records, expose financial information, trigger payments, or grant access to internal systems.

This is the central problem behind enterprise low-code shadow IT risks. Low-code platforms have made software creation accessible to people outside traditional engineering teams. That has real business value: departments can respond to operational needs without waiting for a full development cycle. But the same speed removes several controls that used to appear automatically around software delivery.

A conventional application usually has an owner, a repository, a deployment record, an access model, and a support path. A citizen-built application may have none of these in a reliable form. It can live inside an approved platform and still be an unauthorized production system.

The distinction matters. The platform may be sanctioned. The application built inside it may not be.

The Scale of the Shadow IT Explosion

Enterprise software inventories have always been incomplete. SaaS made that problem more visible because employees could subscribe to services with a card, a private email address, or a self-service trial. Low-code changes the shape of the problem again.

With SaaS, the organization loses track of an external service. With low-code, it can lose track of an internally built application that operates inside an otherwise legitimate tenant.

Research from vendors such as Zenity has drawn attention to the number of low-code applications and development environments that can accumulate inside large organizations. Reports in this area describe enterprises running many more internally created apps than their formal application catalog suggests, sometimes alongside hundreds of sanctioned SaaS products and several low-code platforms.

The exact number is less important than the pattern. A large company can have:

• several low-code and no-code platforms operating at the same time;
• thousands of business-created workflows, forms, dashboards, and integrations;
• applications owned by employees whose responsibilities have changed;
• connectors that reach production systems without a documented data owner;
• test applications that quietly become part of a live business process;
• abandoned apps that continue to retain data or active credentials.

A team does not need to create a sophisticated customer portal for the risk to become material. A workflow that copies a spreadsheet into a collaboration workspace can create a new data store. A form connected to a CRM can expose more fields than the user interface appears to show. An automation that sends records to an external service can bypass the controls applied to the main system of record.

The inventory problem is therefore not just a matter of counting applications. Security teams need to understand what each application does, what it connects to, who can publish changes, and whether anyone still owns it.

This is why traditional SaaS discovery tools do not solve the entire problem. Spend analysis can identify a subscription. Identity logs can reveal a login. Neither necessarily explains that a business user has created a production workflow inside an enterprise-licensed platform.

The first governance failure is often not a breach. It is the absence of a reliable answer to a basic question: what business software is running right now?

The operational arithmetic is also different from conventional development. A professional engineering team may own a limited number of services and maintain a release process around them. A department may create dozens of small automations because each one appears inexpensive and temporary. Individually, they seem harmless. Collectively, they form an application estate with its own attack surface, compliance obligations, and failure modes.

Anatomy of a Breach: Authorization, Authentication, and Secrets

Low-code applications are composite systems. Their behavior comes from the interaction of visual components, platform permissions, data connectors, workflow logic, and external services. The interface can be simple while the underlying access path is not.

Three areas repeatedly deserve attention in citizen-built applications: authorization, authentication, and the handling of data and secrets. These are not a special Gartner framework, and they should not be presented as a single ranked finding from one analyst firm. They are practical risk categories that recur across low-code security guidance and platform reviews.

Authorization misuse

Authorization answers a more difficult question than whether a person can sign in. It determines what that person can read, change, approve, export, or trigger.

A common low-code mistake is to confuse the builder’s access with the end user’s access. The creator can see a table, so the application is connected to the table. The application is then shared with a wider group without an equivalent review of row-level permissions, field visibility, or write access.

The result can be an application where:

• users see records outside their business unit;
• a read-only dashboard exposes fields that should be restricted;
• a form allows updates to a production table;
• a workflow performs actions with the creator’s privileges;
• a shared link provides access beyond the intended audience.

Some platforms offer strong role-based controls, but those controls are not always enabled by default and are not always understood by citizen developers. A canvas with a few fields can conceal a connection that has broad permissions in the underlying system.

The most important question is not whether the app has a login screen. It is whether the platform evaluates the permissions of the person using the application at the point where data is retrieved or an action is executed.

Authentication failures

Authentication is often treated as a platform problem, but low-code applications introduce their own choices. A builder may connect an application through a personal account, a shared credential, an API key, or a service identity created without a clear owner.

Each option creates a different operational risk.

A personal connection can stop working when the employee leaves or changes access. A shared account makes accountability difficult. A long-lived API key can provide persistent access after the application is no longer used. A service identity may have more privileges than the workflow requires because reducing those privileges takes additional configuration.

The danger is especially high when the connection is invisible to the person using the app. The user sees a form or approval screen. The backend may be authenticating to a CRM, database, payment service, or internal API under a different identity entirely.

A secure design should make the connection identity explicit and should establish:

• an accountable owner for each service identity;
• a defined scope of permissions;
• an expiration or rotation process;
• a record of where the credential is used;
• an immediate revocation path;
• monitoring for unusual access and failed authentication.

Data and secrets handling

Low-code platforms make it easy to move information between systems. That convenience can also produce uncontrolled copies of sensitive data.

A citizen developer may store form submissions in a built-in table because it is the fastest way to make the application work. Another may send records to a spreadsheet, collaboration tool, analytics service, or external integration. If the data classification step happens after publication, the application may already have created a new repository that compliance teams did not know existed.

Secrets create a similar problem. API keys, tokens, webhook URLs, and connection details can end up in configuration fields, workflow steps, exported packages, or documentation shared in a team channel. A platform may offer a secure vault or managed connection feature, but the feature has to be required by policy and usable within the builder’s workflow. Otherwise, convenience wins.

The risk is not limited to highly regulated information. Internal pricing, supplier terms, employee data, product roadmaps, and customer support records can all become sensitive when copied into an uncontrolled system.

The right control is to classify data before the connector is approved, not after an incident reveals where the data went. A connector to a public reference dataset should not be governed like a connector to a production customer database. The difference must be visible in the platform and reflected in the approval path.

Low-code security is not mainly about making a visual builder harder to use. It is about making unsafe connections harder to create and easier to detect.

The Governance Gap: Why Traditional IT Oversight Fails

Centralized IT governance was built around scarcity. New software required a budget, a vendor, an implementation project, and a technical team. Those steps created friction, but they also created records. Someone knew when the system was purchased, who supported it, and where it ran.

Low-code removes much of that friction. That is its value. It is also why old oversight models miss the most important events.

Discovery latency

SaaS management tools are good at finding subscriptions, spending patterns, and OAuth activity. They are less effective when a user creates an application inside an approved enterprise tenant. There may be no new vendor, no new invoice, and no obvious change in the identity perimeter.

The relevant event is not a purchase. It is the creation of a workflow, connector, data store, or public endpoint.

Application security tools face a different limitation. Traditional scanners often expect source code, build artifacts, repositories, and deployment pipelines. A low-code app may have no conventional repository and may be modified directly in a browser. The risk is not absent; it is simply expressed in platform metadata, configuration, permissions, and connector behavior.

Identity inheritance

Low-code platforms frequently provide templates and prebuilt connectors to accelerate development. Those defaults are useful for getting a prototype running, but they can encourage an imprecise security model.

The builder may understand which fields the application displays without understanding which permissions the connection holds. A department may understand who needs to use the app without defining who should be able to edit its logic. An administrator may configure the tenant securely while leaving individual applications with excessive sharing settings.

This creates a gap between platform security and application security. A well-configured tenant can still host a poorly authorized application.

Shadow development is different from shadow IT

Shadow IT usually means the unauthorized use of software. Shadow development is the unauthorized construction or modification of software. The second problem is harder to identify because the artifact may be hosted inside an approved environment and may look like ordinary business activity.

A firewall cannot block a workflow created in the company’s own platform. Spend analytics cannot flag an application that uses an existing license. A generic identity report may show that a user accessed the platform without revealing that the user published a customer-data integration.

Effective discovery therefore requires platform-level telemetry. Security teams need events for application creation, publication, connector changes, permission changes, data exports, and ownership changes. They also need a way to distinguish a prototype from a production dependency.

Velocity without a risk tier

Not every low-code application deserves the same review. A personal productivity automation that handles no sensitive data should not wait for the same approval as a workflow that updates financial records.

Without risk tiers, organizations tend to choose between two bad options: approve everything and accept uncontrolled exposure, or impose a heavy review process that drives users toward unapproved tools.

A more workable model classifies applications by factors such as:

1. Data sensitivity: public, internal, confidential, personal, financial, or regulated data.

2. Business impact: informational, operational, customer-facing, or financially consequential.

3. Connection scope: a single low-risk service versus multiple production systems.

4. User reach: one person, a team, an entire workforce, or external users.

5. Change authority: whether the app can approve, delete, publish, pay, or modify records.

6. Availability requirements: whether the business can continue if the app stops working.

The review process can then scale with the consequences. A low-risk internal utility may require registration and automatic controls. A high-impact app may require architecture review, security testing, named ownership, and a support plan.

Mapping the Threat Landscape: Compliance and AI-Assisted Development

The next phase of low-code adoption will not be defined only by visual builders. AI assistants are becoming part of the development experience. They can suggest formulas, map fields, generate workflow logic, describe connectors, and help users troubleshoot integrations.

That can reduce the effort required to build an application. It can also reduce the amount of deliberate reasoning that takes place before publication.

An AI assistant does not need to be malicious to create risk. It may recommend a broad connector because that is the easiest way to complete a task. It may generate a workflow that handles an exception incorrectly. It may encourage a user to copy data into a service whose retention and residency rules are not understood. The builder may accept the suggestion because the result appears to work.

Claims that AI assistance automatically doubles citizen-developer output or creates a precisely measurable future breach surface should be treated cautiously. Publication speed depends on the platform, the task, the user’s experience, and the controls around deployment. The defensible point is narrower: AI can lower the barrier to creating and modifying applications, which increases the need for controls that operate automatically.

The security team cannot rely on every builder to recognize a dangerous field mapping or an overprivileged service account. Guardrails must be close to the action:

• warn when an AI-generated workflow requests sensitive data;
• block connectors that violate data residency or classification rules;
• require a review when a workflow gains write access to a production system;
• record whether AI-generated logic was accepted, changed, or published;
• scan configurations for exposed keys, public links, and excessive permissions;
• make an accountable human owner approve production release.

Compliance failures often begin as configuration failures. A low-code app may store personal information in a location that has not been approved, retain records longer than the business process requires, or allow users to access data without adequate role separation.

The regulatory label varies by industry, but the governance questions are consistent:

• What information does the application process?
• Where is that information stored?
• Who can access it?
• Who can change the application?
• How is the activity logged?
• How long are records retained?
• What happens when the application is retired?
• Can the organization demonstrate control to an auditor?

A platform’s compliance certifications do not automatically cover every application built on it. The organization still has to configure the environment, constrain connectors, assign ownership, and maintain evidence of operation.

Building a Secure Low-Code Framework

Visibility is the starting point, not the finished program. An inventory without enforcement becomes another report that security teams maintain while applications continue to change.

A practical framework should connect discovery, identity, data protection, secrets management, and continuous monitoring. The layers reinforce one another.

1. Establish platform tenancy

Start by identifying which low-code and no-code platforms are in use, including departmental deployments and self-service trials. Consolidation can reduce the number of separate identity models, audit surfaces, and administrative consoles.

The objective is not necessarily to force every team onto one product. It is to establish an approved path with:

• enterprise identity integration;
• centralized logging;
• policy controls for connectors and sharing;
• data-loss prevention capabilities;
• administrative ownership;
• a defined process for exceptions.

Unmanaged platforms should not be treated as invisible simply because they are inconvenient to govern. If they process company data, they belong in the risk picture.

2. Separate builder, publisher, and consumer rights

A person who needs to use an application does not necessarily need to edit it. A person who can build a prototype does not necessarily need to publish to production.

Use separate roles for:

• application consumers;
• builders working in a controlled development space;
• publishers who meet production requirements;
• platform administrators;
• reviewers responsible for data and security decisions.

Production publishing should have an accountable owner and a reason. The process can be lightweight for low-risk applications, but it should create a durable record.

3. Classify data at the connector layer

Reviewing the user interface is not enough. The most important security decision may be the connector behind the screen.

Connectors should carry policy information about the type of data they expose and the actions they permit. A connection to a public API can follow a different path from a connection to employee records or a financial database.

Controls should be able to block or require approval for combinations such as:

• sensitive data sent to an unapproved external service;
• production write access granted to a departmental app;
• personal information stored in a temporary development environment;
• external sharing enabled for an application connected to confidential data.

This is where enterprise governance for low-code platforms becomes operational rather than declarative. The policy must be enforced at the point where the builder creates the connection.

4. Make secrets management mandatory

No-code does not mean credential-free. Every external connection still needs an identity, and every identity needs lifecycle management.

Avoid personal accounts for production integrations. Avoid shared credentials without individual attribution. Do not permit keys to be placed in visible fields, workflow text, exported files, or documentation.

Where the platform supports managed connections or a native secret store, make those mechanisms the default. Where it does not, integrate with the organization’s approved vault and define how credentials are rotated, revoked, and investigated.

A useful test is simple: can the organization identify every application using a credential, rotate that credential without guessing, and determine which user initiated a sensitive action? If the answer is no, the connection is not ready for production.

5. Create environments that match risk

Separate development, testing, and production environments. A builder should be able to experiment without gaining unrestricted access to live data.

Environment controls can include:

• approved data sources;
• restricted export functions;
• limited external sharing;
• separate service identities;
• retention rules;
• mandatory reviews for production promotion;
• automatic expiration for prototypes.

Temporary applications should have an expiration date. If the owner does not confirm the business need, the app should be archived, disabled, or removed according to policy. This is more reliable than expecting a central team to discover abandoned tools years later.

6. Monitor behavior continuously

Annual review is not compatible with applications that can be created and changed every day. Monitoring should focus on events that alter exposure:

• a new application is published;
• a connector is added or changed;
• a public or external share is enabled;
• a service identity gains broader permissions;
• a large data export occurs;
• ownership changes;
• an inactive application becomes active again.

These events should feed the organization’s existing detection and response process where possible. Low-code telemetry is not a separate universe. A suspicious export from a workflow belongs beside other data-access signals.

7. Give departments a safe path

Governance fails when it only says no. If employees cannot obtain an approved connector, environment, or review within a reasonable time, they will search for a workaround.

A secure low-code program should provide reusable components, approved templates, documented data patterns, and clear escalation routes. It should also train citizen developers in the risks that are specific to their work: inherited permissions, connector scope, retention, secrets, and production ownership.

The goal is not to turn every analyst into a security engineer. It is to make the secure option the easiest option.

What Secure Citizen Development Looks Like

Managing shadow IT in large organizations is not a campaign to eliminate every unofficial application. Some shadow development exists because the formal delivery process does not serve small but legitimate needs. If governance ignores that reality, the organization will preserve the demand and merely push it into less visible channels.

The better approach is to distinguish useful experimentation from uncontrolled production dependency.

A low-risk internal form may need registration, approved storage, and automatic expiration. A customer-facing workflow needs stronger identity controls, documented ownership, testing, monitoring, and a recovery plan. An application that changes financial or employment records should be governed like a business-critical system, regardless of whether it was built with code or drag-and-drop components.

That is the shift many organizations have not yet made. They classify software by how it was built rather than by what it can do.

Low-code applications should be subject to controls proportionate to their impact:

• Prototype: isolated data, limited users, no production write access, short lifetime.
• Departmental tool: named owner, approved connectors, role-based access, basic monitoring.
• Operational application: documented dependencies, controlled publishing, backup and recovery, continuous audit.
• Business-critical system: formal architecture and security review, tested resilience, separation of duties, incident response coverage.

The categories do not need to be identical across platforms. They do need to be understandable to the people building the applications.

The right response to citizen development is not a larger approval queue. It is a smaller number of dangerous defaults.

Governance Must Catch Up With the Builder

Low-code did not make enterprise software inherently insecure. It changed who can create it, how quickly it can change, and where the evidence of that change is stored.

That makes unauthorized no-code app development a governance problem as much as a technical one. Security teams need visibility into platform activity, but visibility alone will not protect a company from an overprivileged connector or an abandoned application with a live credential.

The durable controls are practical:

• inventory applications, platforms, connectors, and owners;
• separate building from publishing;
• classify data before connections are approved;
• use managed identities and rotate secrets;
• isolate prototypes from production;
• monitor publication and permission changes;
• retire applications that have lost their owner or business purpose;
• give departments an approved path that is faster than bypassing IT.

Forecasts about the future scale of low-code adoption and shadow technology vary, and precise predictions about when a breach will occur should not substitute for evidence. The risk is already visible in the structure of the systems: more people can create software, more software can reach sensitive data, and more of that activity can happen without passing through a conventional delivery pipeline.

The question is not whether citizen development will exist. It already does. The question is whether the organization will treat those applications as real software—with real owners, real permissions, real data obligations, and real consequences—or continue to mistake an approved platform for an approved application.