What breaks when low-code automation and identity governance are not separated in SAP BTP?

Where separation fails in SAP BTP

The problem is not low-code by itself, it is mixing build-time authority with run-time authority. In SAP BTP, a maker who can assemble a workflow, connector, or approval path should not automatically inherit the ability to execute that flow across business systems. Once those duties blur, the platform starts to behave like a privilege multiplier instead of a governed automation layer.

That is why identity governance has to be treated as a separate control plane, not a feature inside the same maker experience. The design question is not whether the workflow works, but who can publish it, which identities it runs as, and whether the workflow’s permissions are narrower than the person who created it.

When teams keep those layers distinct, the workflow stays bounded by explicit approvals, scoped service identities, and reviewable entitlements. When they do not, the automation can inherit broad access from the creator, the environment, or a shared connector, which makes the resulting control model much harder to reason about after deployment.

What actually expands when maker and governance roles collapse

The first thing that expands is blast radius. A low-code workflow can span data sources, line-of-business systems, notification channels, and approval chains, so one overextended permission can reach far beyond the original app or form. The second is privilege creep: access granted to speed up development often survives long after the workflow is live.

That is also where ownership gets fuzzy. If the same person can design the process, change the connector, and approve the exception, there is no clean separation between business intent and operational control. In practice, that means a single account may be able to create, modify, and trigger actions that should have been independently reviewed.

For practitioners, the key failure mode is not merely excessive access at one point in time. It is the combination of reusable connectors, persistent credentials, and broad publish rights that turns a low-code artifact into a durable path to systems that were never meant to be directly reachable from the maker role.

Why governed separation matters for SAP BTP automation

Governance has to distinguish who can build from who can authorize execution, and who can authorize execution from what the workflow can touch. That separation is what prevents a convenient automation from becoming an implicit superuser path. NHIMG’s IAM and IGA Basics is a useful reference point for that distinction because the control problem is fundamentally about entitlements, reviews, and least privilege.

Review discipline matters just as much as role design. If a workflow can approve payments, change records, or update access, then the flow itself becomes a privileged business action and should be reviewed like one. The strongest Segregation of Duties (SoD) Guide issue here is not abstract policy, it is preventing one workflow designer from also controlling the downstream action that the workflow initiates.

Lifecycle controls matter too, because published automations do not become safer over time on their own. NHIMG’s IGA Buyer's Guide and Access Reviews and Certification Guide both support the same operating principle: low-code access needs periodic recertification, not just initial approval.

Risk and Threat Considerations

When maker access and governance are merged, the main risk is that an apparently low-risk authoring permission becomes a path to operational abuse. A compromised maker account, an overbroad shared connector, or a poorly reviewed exception can let an attacker or insider turn an ordinary workflow into a trusted channel for data access, approval abuse, or unauthorized business actions.

Failure mechanism: The workflow designer gains or inherits the permissions needed to publish and run automations against systems that were supposed to be independently controlled, so the platform amplifies one account into multi-system access.

Impact: A single compromise or privilege mistake can affect multiple connected services, which increases blast radius, complicates detection, and makes rollback harder because the automation may keep executing with valid business credentials.

Practitioner Guidance

What to prioritise: Separate maker permissions, publish permissions, and runtime service access before you scale low-code use. If those three capabilities live in one role, the platform is already overstating trust.

What to verify: Check which identity actually executes each workflow, which connections it inherits, and whether the workflow can touch production data or approval paths without a second control. If the answer is “the creator can do all of it,” treat that as a design defect, not an admin convenience.

Common mistake: Teams often secure the app platform and forget the workflow runtime. That leaves a gap where approved automation can still become an uncontrolled privilege bridge once it is published.

Practitioner takeaway: The right control objective is not to slow down low-code, but to ensure that building automation never implies the authority to operate it across domains the maker was not meant to control.

Related resources from NHI Mgmt Group

• How should security teams govern low-code automation in SAP BTP environments?
• Why is it important to integrate identity and data governance?
• What breaks when identity governance is separated from data security?
• What breaks when risk management is separated from identity governance?