A citizen developer is a business user who builds or connects workflows without traditional software engineering expertise. In eSignature programmes, that can speed adoption, but it also increases governance demands because access scopes, connector permissions, and secret handling may be created outside standard engineering controls.
Expanded Definition
Citizen developer is not just a convenience label for “business user who can build.” In NHI and IAM contexts, it usually means a non-engineering operator assembling automations, integrations, or low-code workflows that can touch identities, secrets, and approvals. Usage in the industry is still evolving, and definitions vary across vendors, but the governance question is stable: who can grant access, where are credentials stored, and how are changes reviewed? That matters because citizen-built workflows often sit between SaaS tools, e-signature systems, and internal records, creating hidden identity dependencies that are easy to miss in NIST Cybersecurity Framework 2.0 terms such as access control, asset visibility, and secure change management.
For NHI teams, the key distinction is that a citizen developer is not the same as an application owner or a platform engineer. They may be creating service connections, API bindings, or approval logic without a full understanding of NIST Cybersecurity Framework 2.0 safeguards, which is why policy guardrails must compensate for limited technical depth. The most common misapplication is treating citizen-built automations as low-risk just because they are built outside code review, which occurs when connector access and secret handling are granted informally through business-led change requests.
Examples and Use Cases
Implementing citizen development rigorously often introduces slower approvals and tighter platform constraints, requiring organisations to weigh speed of delivery against control over secrets, RBAC, and connector scope.
- A legal operations specialist configures an e-signature workflow that routes contracts for approval, but only if connector scopes are limited and reviewed under NIST Cybersecurity Framework 2.0 access governance principles.
- A finance analyst builds a no-code reconciliation flow that reads from a document repository and triggers alerts. If tokens are copied into a shared workspace, the workflow can become a secret exposure path similar to cases discussed in Google Firebase misconfiguration breach.
- An HR coordinator creates an onboarding automation that provisions access requests for new hires. That can be efficient, but it should be constrained by role-based approval steps and least-privilege defaults, not by ad hoc permission grants.
- A procurement team links a vendor portal to internal records. If the workflow stores long-lived API keys outside a secrets manager, the result is not just convenience, but an identity dependency that must be treated like an NHI control problem.
Citizen development is most defensible when the platform enforces templates, pre-approved connectors, and central logging. It becomes risky when business users can bypass review to connect production systems directly, a pattern that often appears in shadow automation after teams adopt tools faster than governance can adapt. The same failure mode is visible in incidents such as the Google Firebase misconfiguration breach, where easy-to-use infrastructure became a governance gap.
Why It Matters in NHI Security
Citizen developers matter because they frequently create the exact conditions that produce unmanaged NHIs: service accounts, API keys, shared secrets, and overbroad connector permissions. NHIMG research shows that 30.9% of organisations store long-term credentials directly in code, and that pattern often expands when non-engineers are allowed to publish workflows without security controls. The business risk is not the citizen developer role itself, but the absence of guardrails around identity lifecycle, secret rotation, and access review.
This is where NHI governance intersects with operational reality. A business-led automation may appear harmless until a credential leaks, a connector is over-permissioned, or an ex-employee’s workflow continues to run. At that point, response teams need a clear answer to who owns the workflow and which secrets it can reach. Guidance from NIST Cybersecurity Framework 2.0 reinforces the need for inventory, protection, detection, and recovery, while NHI-specific failures are often exposed through incidents like the Google Firebase misconfiguration breach.
Organisations typically encounter the real cost only after a leaked token, broken approval flow, or unauthorised data pull forces an incident review, at which point citizen development becomes operationally unavoidable to address.
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 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 | Addresses improper secret handling and exposed credentials in NHI workflows. |
| NIST CSF 2.0 | PR.AC-4 | Maps to access management and least-privilege enforcement for workflow tools. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires verifying every workflow identity and connector call. |
Treat each citizen-built integration as untrusted until its identity, scope, and logging are validated.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
