What do security teams get wrong about low-code apps in industrial IT?

They often treat low-code apps as lightweight productivity tools instead of governed systems that can influence access, incidents, and operational change. If an app can approve work, route requests, or expose data used in production decisions, it needs role review, retention rules, and ownership like any other control-bearing application.

Why This Matters for Security Teams

Low-code apps in industrial IT are often dismissed as harmless workflow glue, but many of them act as control-bearing systems. When an app can approve maintenance, route incident data, or expose operational records, it becomes part of the trust boundary. That means access review, change accountability, retention, and ownership matter just as much as they do for conventional applications. NIST’s identity guidance makes the core point plainly in NIST SP 800-63 Digital Identity Guidelines: identity assurance only works when access decisions match the actual risk of the transaction.

The common mistake is to treat the platform as low risk because the development effort is low code. In industrial environments, that assumption is dangerous. A small app can still influence production decisions, trigger notifications to the wrong team, or leak sensitive data into a vendor workflow. NHIMG research on The State of Non-Human Identity Security shows how often visibility and privilege gaps become real attack paths, especially when governance is weak.

In practice, many security teams discover the impact of a low-code app only after it has already been used to move work, expose data, or approve a change that should have required stronger review.

How It Works in Practice

The right way to manage low-code apps in industrial IT is to classify them by function, not by build effort. If an app can read production data, route approvals, trigger tickets, or write to downstream systems, it needs an owner, a business purpose, and explicit control mapping. That includes role review, logging, retention, and a clear offboarding path when the app is retired or repurposed.

Security teams should also distinguish between the app platform and the identity it uses. A low-code app may rely on service accounts, API keys, or delegated OAuth permissions. Those are non-human identities, and they need the same lifecycle controls as any other privileged workload. NHIMG’s Ultimate Guide to Non-Human Identities highlights the scale of the problem: secrets are frequently stored in unsafe places, over-privilege is common, and rotation often fails to happen on time.

• Assign a named business owner and a technical owner for every app.
• Review who can create, approve, and change workflows, not just who can log in.
• Map app permissions to production impact, including any write access to operational systems.
• Store credentials in approved secrets management paths and rotate them on a defined schedule.
• Log approval actions, data exports, and connector activity for audit and incident response.

For identity assurance, use the strongest practical controls available. In modern environments that often means pairing policy review with workload identity, short-lived tokens, and least privilege, rather than leaving the app on long-lived credentials that outlive the business need. These controls tend to break down when low-code platforms are integrated directly into OT-facing workflows because legacy dependencies make ownership, logging, and revocation incomplete.

Common Variations and Edge Cases

Tighter governance often increases process overhead, so teams have to balance speed for operators against control for production-impacting workflows. Best practice is evolving here, and there is no universal standard for every industrial low-code pattern. A simple request form is not the same as an app that authorises maintenance or writes to a plant dashboard.

Some edge cases need extra caution. Citizen-built apps used for shift handover can become shadow control paths if they start informing dispatch decisions. Vendor-built low-code workflows may hide delegated permissions behind a friendly interface, making it harder to see the actual identity and data exposure. In those cases, security teams should treat the connector, token, and approval trail as first-class assets, not implementation details.

Industrial teams also get caught by retention and evidence gaps. If an app records incident notes, operator acknowledgements, or exception approvals, those records may be needed for audit, safety review, or post-incident analysis. The control question is not whether the app is simple, but whether it influences a decision that matters. When that is true, the app belongs in the governed application inventory alongside other systems that can affect operations.

Related resources from NHI Mgmt Group

• What do security teams get wrong about app consent and low-code integrations?
• What do security teams get wrong about posture reports that list hundreds of findings?
• What do security teams get wrong about conditional access exclusions?
• What do security teams get wrong about Active Directory change confirmation?