Citizen development expands who can create software-like workflows, which increases the chance of misconfigured access, unintended data exposure, and weak oversight. When non-traditional builders can connect systems quickly, security depends less on central review and more on policy, identity controls, and ongoing visibility into how applications are assembled and used.
Why This Matters for Security Teams
Citizen development changes the risk profile because software creation stops being confined to trained engineering teams with established review gates. Low-code and no-code builders can connect SaaS apps, data sources, and automations quickly, which is valuable for speed but dangerous when identity, data handling, and approval paths are weak. The main risk is not just bad code, but uncontrolled access paths that bypass normal application security discipline. This is why NHIMG research on the Top 10 NHI Issues consistently frames identity sprawl and weak oversight as core failure modes, not edge cases. NIST’s NIST Cybersecurity Framework 2.0 also reinforces that governance, access control, and continuous monitoring matter as much as build-time checks. The shift is operational: security teams must manage who can assemble workflows, what those workflows can reach, and how changes are detected after deployment. In practice, many security teams encounter exposure through citizen-built workflows only after data has already been shared broadly or an integration has been abused, rather than through intentional design review.
How It Works in Practice
The practical change is that risk moves from a small number of controlled release pipelines to many distributed builders creating business logic in day-to-day tools. That means the security boundary is no longer only the application repository. It now includes connector permissions, delegated OAuth grants, shared service accounts, embedded secrets, and the data permissions attached to each workflow. NHIMG’s Ultimate Guide to NHIs is useful here because many citizen-built automations behave like NHIs in practice: they authenticate non-interactively and can persist long after the original creator has changed roles or left.
- Restrict which connectors can be used, and classify them by data sensitivity.
- Use role-based guardrails for builders, but do not rely on RBAC alone to protect runtime actions.
- Prefer short-lived tokens and scoped delegated access over shared secrets and permanent credentials.
- Log every workflow change, connector grant, and outbound data transfer for review.
- Require security-approved patterns for systems that touch customer, financial, or regulated data.
Current guidance suggests treating each workflow as a production integration, even when it was created by a business user. That means the approval model should focus on runtime permissions, not just who was allowed to click “publish.” The security control point is the identity behind the automation, plus the data path it can traverse. NIST CSF 2.0 is helpful for mapping this to governance and monitoring outcomes, while the 2024 ESG Report: Managing Non-Human Identities underscores how often identity-driven failures become real incidents once monitoring and rotation are weak. These controls tend to break down when citizen developers can create cross-system automations with inherited admin privileges and no central telemetry.
Common Variations and Edge Cases
Tighter control over citizen development often increases delivery friction, requiring organisations to balance speed against approval overhead. The main tradeoff is that blanket restrictions can push users toward shadow IT, while overly permissive self-service creates silent exposure. Best practice is evolving, but there is no universal standard for this yet: the right balance depends on whether the workflows handle internal productivity data, regulated records, or customer-facing operations.
Edge cases matter. A simple approval workflow may be low risk until it starts pulling from HR, finance, or CRM systems. A prototype automation may become critical once it is embedded in operations and no one remembers who owns it. This is where continuous discovery, ownership assignment, and periodic access recertification become essential. Security teams should also distinguish between citizen-developed front-end logic and behind-the-scenes machine identities that actually move data, because the latter often outlive the former. For broader background on non-human identity exposure patterns, see NHIMG’s OWASP NHI Top 10 and the Ultimate Guide to NHIs. The practical lesson is simple: citizen development is not insecure by default, but it makes identity, data, and oversight the primary control plane.
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, CSA MAESTRO and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OV | Citizen development needs governance and oversight of distributed workflows. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Citizen-built automations often rely on non-human identities and tokens. |
| CSA MAESTRO | IDM | Citizen development creates new identity and access paths that need control. |
| NIST AI RMF | The same governance issues apply when AI-assisted builders assemble workflows. | |
| OWASP Agentic AI Top 10 | A1 | Autonomous or semi-autonomous workflows can expand access beyond intent. |
Control runtime access for each automation and validate delegated permissions continuously.
Related resources from NHI Mgmt Group
- Why do AI features in low-code and no-code platforms change the risk profile for application development?
- Why do external model integrations change the risk profile for security products?
- How should security teams manage application risk in fast-moving development environments?
- Why do hidden APIs and microservices increase application security risk in modern development?
