Citizen development is the practice of allowing non-traditional developers to build applications, automations, or workflows using accessible tools. It can improve speed and productivity, but it also introduces governance, access, and data protection risks unless security teams define clear boundaries and review points.
Expanded Definition
Citizen development is the controlled practice of enabling business users and other non-traditional developers to build applications, automations, or workflows with low-code or no-code tools. In NHI and IAM environments, the term matters because these builders often interact with NIST Cybersecurity Framework 2.0 functions such as access control, data protection, and change management even when they do not operate as formal software engineers.
Definitions vary across vendors, but in practice citizen development should not mean unrestricted self-service. It is safer to treat it as a governed delivery model with pre-approved connectors, scoped credentials, logging, and review gates. That distinction matters because workflow tools can silently create new service accounts, API keys, and secrets that become part of the NHI estate. NHI Management Group’s Ultimate Guide to NHIs shows how quickly unmanaged identities and secrets expand attack surface when visibility is weak. The most common misapplication is equating ease of use with safe ownership, which occurs when teams allow business users to connect production data sources without security review.
Examples and Use Cases
Implementing citizen development rigorously often introduces friction between speed and governance, requiring organisations to weigh rapid workflow delivery against tighter controls on data, identity, and approval paths.
- A finance team builds an invoice approval workflow in a low-code platform, but security requires least-privilege service credentials and quarterly access reviews before production use.
- A sales operations group automates lead routing, while IAM teams restrict which data connectors can be used and log every external API call for auditability.
- A human resources team creates an onboarding app that writes to multiple systems, and each integration must use separately scoped secrets instead of a shared administrator token.
- A facilities team publishes a request form that triggers privileged actions, so the approval chain is separated from execution rights to avoid direct end-user privilege escalation.
- A regional business unit prototypes a chatbot workflow, then formalises it only after a security team validates secrets handling, retention rules, and rollback procedures.
For a broader view of identity sprawl in modern enterprises, NHI Management Group’s Ultimate Guide to NHIs is especially useful when citizen-built automations begin to depend on service accounts. Where workflow authorization or system-to-system trust is involved, implementation guidance often aligns with identity federation patterns described by NIST Cybersecurity Framework 2.0.
Why It Matters in NHI Security
Citizen development becomes an NHI security issue the moment non-technical builders start creating persistent automations with credentials, tokens, or certificates. NHI Management Group reports that 79% of organisations have experienced secrets leaks and 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which makes low-code sprawl a real governance concern rather than a productivity footnote. The risk is not the tool itself, but the hidden identity layer it creates underneath the workflow.
Without defined ownership, citizen-built apps can leave behind orphaned secrets, overbroad connector permissions, and undocumented data paths. That is why security teams need inventory, review points, and revocation procedures before production deployment, not after a breach review. The Ultimate Guide to NHIs also shows that many organisations lack full visibility into service accounts, which makes citizen development especially risky when apps are handed off between departments. Organisational impact typically becomes visible only after an unexpected integration failure, at which point citizen development is operationally unavoidable to govern.
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, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Citizen apps often create and misuse secrets, directly overlapping with secret management risk. |
| NIST CSF 2.0 | PR.AC | Low-code workflows still depend on access control, least privilege, and auditability. |
| NIST Zero Trust (SP 800-207) | Citizen development should not assume implicit trust across apps, users, and connectors. | |
| OWASP Agentic AI Top 10 | Citizen-built automations can behave like agents when they execute actions and call tools. | |
| CSA MAESTRO | Governance patterns for agentic systems apply when citizen tools perform multi-step actions. |
Inventory every connector secret, restrict storage locations, and rotate credentials on a fixed cadence.
Related resources from NHI Mgmt Group
- Why do enterprise copilots and citizen development tools create new governance risks for identity and data security?
- What breaks when organisations scale app security without a clear model for citizen development?
- How should teams combine SAST and DAST in a secure development programme?
- How should teams reduce secrets exposure in AI-assisted development?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
