Subscribe
Share
Share
Embed
Welcome to Bare Metal Cyber, the podcast that bridges cybersecurity and education in a way that’s engaging, informative, and practical. Hosted by Dr. Jason Edwards, a seasoned cybersecurity expert and educator, this weekly podcast brings to life the insights, tips, and stories from his widely-read LinkedIn articles. Each episode dives into pressing cybersecurity topics, real-world challenges, and actionable advice to empower professionals, educators, and learners alike. Whether navigating the complexities of cyber defense or looking for ways to integrate cybersecurity into education, Bare Metal Cyber delivers valuable perspectives to help you stay ahead in an ever-evolving digital world. Subscribe and join the thousands already benefiting from Jason’s expertise!
The outage starts with a shrug. A sales operations analyst clicks into the low-code app the team has been using “just for this quarter” to wrangle approvals and pricing exceptions, and it spins. Then it errors. Within an hour, regional leaders are asking why deals are stuck, finance is worried about forecast accuracy, and somewhere in the backlog for information technology (I T) there is exactly zero mention of this application that now holds thousands of customer records. There is no change ticket, no architecture review, no risk assessment. Just a business-critical workflow balanced on a tool one power user built on a quiet Friday afternoon.
Welcome to the narrated edition of “Citizen Developers, Enterprise Risk: Low-Code Apps You Didn’t Approve,” part of the Wednesday “Headline” feature from Bare Metal Cyber Magazine, developed by Bare Metal Cyber. Citizen development is no longer a side story. Low-code and no-code platforms promise to unlock innovation at the edge of the business, and they do. They also create a parallel universe of unapproved but indispensable apps that sit outside traditional governance, monitoring, and recovery plans. Over the next few years, the risk profile here will be shaped less by any specific platform and more by how leaders choose to channel or ignore this energy.
In most organizations, the story starts with a backlog and a promise. A business team has been waiting months for a small workflow change, a simple approval flow, or a more usable interface to a core system. The central product or I T team agrees it is reasonable, but it keeps losing to higher profile initiatives. Then a power user discovers that with a low-code platform they can stitch together a form, a few connectors, and some basic logic over a weekend. They show it to their manager on Monday, it solves a real pain, and everyone quietly agrees to try it “just for this quarter.” No one fills out a project intake form, and nobody thinks to ask security for an architecture review.
Fast-forward six months and that temporary app has become the way the organization does business in that slice of the world. New hires are onboarded into it. Regional leaders demand new features. A director in finance depends on its exported data for weekly forecasts. The original creator is now the de facto product owner, admin, and support desk, all while doing their day job. There is still no asset record, no change history, and no clear mapping between the app’s permissions and the organization’s identity model. From the perspective of central I T and security, this app does not exist. From the perspective of the business, it is mission-critical.
Leaders usually first encounter these apps at their worst moment: during an outage, an audit, or a data discovery exercise after a near miss. Someone asks who owns the application, who approved its access to sensitive data, or how it is backed up, and the room goes quiet. The point is not that citizen developers are reckless. Often they are resourceful and deeply committed to solving real problems. The deeper problem is that a parallel system of work has been allowed to emerge without a matching system of control. Once you see that pattern, you can stop treating these apps as isolated policy violations and start treating them as a design problem in your operating model.
If you look at the incentives, shadow low-code apps are not a surprise; they are the default outcome. Most large enterprises run on a permanent tension between demand and capacity. Business teams are pushed to hit aggressive targets, streamline processes, and respond to shifting markets. Central I T is juggling legacy platforms, compliance projects, and a queue of transformation initiatives that already spans quarters. When a low-code platform appears in that environment with a glossy promise of “build what you need yourself,” it is not a rogue act for a manager to say yes. It is rational behavior under pressure.
Vendors play into this by framing low-code as inherently safe and governed. The marketing story is that every app lives inside a blessed platform, wrapped in enterprise identity, network, and data controls. In practice, the moment you allow broad self-service creation, you are encouraging thousands of micro-decisions about data sources, connectors, sharing, and automation to be made by people whose primary job is not risk management. They are optimizing for time to value, not for auditability, least privilege, or long-term maintainability. The platform may be secure by design, but the compositions built on top of it are only as thoughtful as the least rushed project.
Policies that try to ban or heavily restrict citizen development usually backfire. When the official stance is “no unsanctioned apps,” but the lived reality is “we cannot get your work into the roadmap this year,” people simply move to whatever tool they can reach. That might be unsanctioned software as a service (S A A S), sprawling spreadsheets, or low-code platforms tied to their corporate identity but still invisible to governance. At that point, you no longer face a choice between citizen development and central delivery. You face a choice between shaped citizen development in view of your controls, or unmanaged improvisation in the dark. Recognizing shadow apps as inevitable is the first step toward designing an operating model that assumes their existence and builds a risk envelope around them.
When a low-code app fails, the root cause is almost never a single bug. It is a stack of quiet decisions that accumulated over time. A power user chooses a connector that offers broad access because it just works, rather than a narrowly scoped alternative. A business owner grants sharing to everyone in a department to avoid access tickets. Someone wires an automation that copies data to a personal workspace for backup. None of these choices look catastrophic in the moment. Taken together, they create an app with more privilege than it needs, more reach than anyone intended, and more hidden dependencies than anyone remembers.
You can picture a typical failure. The app uses a generic service account or an over-privileged connector to reach into a core platform because that was the only way to get data flowing quickly. The citizen developer leaves the company or changes roles, and the account is disabled during an access review. Suddenly, workflows stall, and no one connects the outage to the “small” app that had quietly become the glue between systems. In another scenario, a convenient integration ends up syncing sensitive data into a location that falls outside your monitoring and data loss controls. An audit or incident response exercise later surfaces an unexpected cache of regulated records in a place nobody thought to check.
From a leadership perspective, these failures are not about bad people making reckless choices. They are about an architecture and operating model that pushes core risk decisions to the edge without giving people the tools to understand the blast radius. The common ingredients are over-privileged access, unclear identity mapping, informal ownership, a lack of meaningful audit trails, and brittle error handling that surfaces as “it just stopped working.” If the reaction is only to blame the last person who touched the app, the systemic lesson is lost. The control plane did not extend to where the work was actually happening, and the system behaved exactly as designed.
If your only response is to lock everything down, you lose twice. The shadow apps do not disappear, and the people closest to the work stop telling you what they are building. The governance challenge is to acknowledge that citizen developers are solving real problems, then design a system that makes the safe path the easiest path. That starts with a clear, positive stance. Low-code and no-code are welcome in the organization as long as they live on sanctioned platforms with guardrails and visibility. Instead of a blanket “no,” leadership describes where and how this kind of building is encouraged.
Practical guardrails turn that stance into reality. Sanctioned platforms with preconfigured environments give you a place to point people that is both safe and usable. Curated connector catalogs help citizen developers avoid the most dangerous patterns by limiting access to well understood systems and data classifications. Templates and reference apps embody good design choices around identity, least privilege, logging, and error handling without requiring every business user to become a security architect. A lightweight registration flow, integrated into the act of creating an app, can capture basic metadata like owner, purpose, data sensitivity, and expected lifespan at the moment when people are most engaged.
Culture matters as much as controls. A citizen developer community of practice gives these builders a home, peers, and a visible relationship with security and architecture teams. Training that focuses on how to keep your app from hurting colleagues or customers lands better than abstract threat lectures. Office hours with a small enablement squad can turn potential violations into design improvements before they ship. The message is that security is part of the value proposition, not a distant gate. When sanctioned platforms, sensible guardrails, and an affirmative culture come together, it becomes easier for people to build in the open and harder for risky patterns to survive unnoticed.
To make citizen development sustainable, you need a control plane that moves at two speeds without tearing itself apart. At one speed, central engineering and security teams define durable foundations like identity, data classification, logging, monitoring, backup and restore, change management, and incident response. At the other speed, business teams iterate quickly on workflows, forms, and automations that sit close to the work. Many organizations try to run both speeds through the same process, and that is where things break. Either everything is forced through heavyweight gates designed for core platforms, or everything is left to local improvisation.
A two-speed model accepts that low-code apps will move faster, then deliberately builds shared rails they cannot fall off. In practice, that means standard reference architectures for common low-code use cases. Apps that read from a customer data system but do not write back might have one pattern. Apps that trigger financial transactions might have another, with tighter controls and review. Central teams expose these patterns through preconfigured environments and policies inside the low-code platform itself. Automated enforcement through conditional access, data policies, environment isolation, and baseline logging is far more reliable than a patchwork of manual reviews.
This model also clarifies escalation and evolution. Citizen-built apps that start small but show signs of becoming core can move into a higher tier with more formal lifecycle management, additional testing, and stronger recovery requirements. That transition should not feel like an ambush. It should be a planned pathway that recognizes success, not a punishment for popularity. Leaders set thresholds for data sensitivity, transaction volume, regulatory impact, and dependency counts that trigger a change in status. When those thresholds are explicit and built into monitoring and portfolio reviews, you avoid the worst surprise: finding out in the middle of an incident that a small workflow helper has grown into a pillar of a critical process.
You also cannot manage this space if you only see it anecdotally. For citizen-built low-code apps, ownership starts with a credible inventory and a shared understanding of who is accountable for each application’s behavior. That does not mean turning every business user into a formal product owner with a thick charter. It does mean that any app touching meaningful data or workflow has a named business sponsor, a visible primary maintainer, and a clear relationship to the central platform and security teams. The platform itself can help by capturing creation logs, registration data, and environment metadata that together form a living catalog.
Once you have a picture of what exists, metrics become useful. Raw counts are not enough. Saying you have hundreds of low-code apps is more noise than signal. What leaders need is a view of coverage and concentration. How many apps live in sanctioned environments with basic guardrails applied? What percentage have a named owner and a tagged data sensitivity level? How many tie into core systems such as customer, finance, or human resources (H R), and how many of those sit in higher control tiers? Over time, trends matter: the growth rate of registered versus unregistered apps, the proportion monitored by logging and alerting, and how many have had at least one lightweight review.
Citizen development risk also has to sit in the same places as other technology risks. That means in the risk register, in internal audit planning, and in the narratives used for executives and boards. Someone has to make explicit choices about where the residual risk of low-code apps sits, often with the business function that owns the process rather than only with I T. Those choices should be captured in the same language used for third-party providers, cloud platforms, or legacy systems. Supporting stories help too: examples where structured governance avoided an incident, and cases where a lack of ownership created unnecessary pain.
At its heart, this topic is about owning the gap between where work actually happens and where your controls currently reach. Citizen developers are not a fringe. They are the people keeping the business moving when formal roadmaps cannot. The low-code apps they build are not accidents; they are responses to real friction. Seen through that lens, the question changes from how to stop these apps to how to build a safety envelope around something that clearly delivers value. The risk is not that people are building; the risk is that they are building in a space your governance barely touches.
Closing that gap means accepting that unapproved often just means unseen. By bringing low-code into sanctioned platforms, curating guardrails, and designing a two-speed control plane, you replace improvisation in the dark with experimentation in the light. You stop treating every citizen app as either harmless or catastrophic and start grading them by data sensitivity, dependency, and blast radius. Ownership becomes a matter of explicit sponsorship and transparent metrics instead of folklore. Conversations shift from “Who built this thing?” to “Which tier is it in, who owns it, and what happens if it fails?”
A useful next step for any leader is simple. In your next leadership meeting, ask where low-code apps already sit in critical processes, who feels responsible for them, and what would happen if two of those citizen developers left tomorrow. The answers will tell you how urgent this risk really is and where to begin. From there, the work is not to shut down citizen development, but to give it a visible place inside your risk story, before an incident forces that story to be written for you.