Low-Code Platform Security: What to Check Before You Roll One Out

Most low-code security writing lists risks. This is the other document: the questions that decide whether a platform passes review, grouped by the three places access actually leaks. Access to the platform, access to the data, access to production. A checklist you can paste into an email to a vendor is at the end. If you only read one section, read the one on row-level permissions, because it is the control most platforms skip and most reviews forget to ask about.

Three layers, not one long list of risks

A low-code platform sits between your identity provider and your production database, which means a review has to cover three separate surfaces. Treating them as one list is how teams end up with a platform that has flawless SSO and no idea who deleted a customer record.

The first layer is access to the platform: who can log in, who can build, who can publish. The second is access to the data: what a given user can see once they are in, and whether that limit is enforced on rows or only on screens. The third is access to production: what happens between someone changing an app and that change reaching real customers.

Each layer fails differently. Platform access fails through orphaned accounts. Data access fails through a filter someone can remove. Production access fails through an app that went live on Friday afternoon with no review and no way to roll it back.

Single sign-on, and why the checkbox means little

Almost every platform claims SSO. The claim is close to meaningless on its own, because SSO covers authentication and says nothing about lifecycle.

What matters is what happens on the day someone leaves. If the platform supports SAML but not SCIM provisioning, deactivating a person in your identity provider does not remove their access. It stops them starting a new session through the identity provider, and that is all. Local accounts, API tokens and existing sessions can survive, sometimes indefinitely.

So the questions are narrower than "do you support SSO". Which protocol, SAML or OIDC. Is SCIM supported for provisioning and deprovisioning, or is user removal manual. Can local password login be disabled entirely once SSO is on, or does it remain as a fallback that nobody monitors. Are group memberships from the directory mapped to roles in the platform, or are roles assigned by hand and drift within a quarter. How long does a session live, and can that be configured.

A platform that answers the SCIM question with "it is on the roadmap" is a platform where offboarding is a manual process. That may be acceptable at twelve users and is not at two hundred.

Row-level permissions, the control that gets skipped

This is the difference between a tool that can face customers and one that cannot, and it is where a surprising number of platforms quietly fail.

Screen-level permissions decide which pages a role can open. Row-level permissions decide which records a user can see on a page they are allowed to open. Many platforms implement the first, call it granular access control, and leave the second to whoever builds the app.

When the second is left to the app builder, the usual implementation is a filter on a query. That filter is a UI convention, not a security boundary. If the underlying query can be reached another way, through an API endpoint the platform exposes, through a component that was configured without the filter, or through a copy of the page that someone duplicated and edited, the data comes back unfiltered.

The test to run during evaluation takes ten minutes and is worth more than any datasheet. Build a two-record dataset belonging to two different users. Log in as the first. Then change the record identifier in the URL, and separately call whatever API the platform exposes for that resource, using the first user's session. If either returns the second user's record, permissions are being enforced in the interface and not in the data layer. Ask how that is fixed, and treat the answer as a product question rather than a configuration one.

Audit logs that survive an incident

The question a review asks is "who changed this record". The question that decides whether you can answer it is what the platform logs, for how long, and where the log goes.

Distinguish two different logs, because vendors often have one and imply both. A builder audit log records changes to apps: who edited a page, who changed a permission, who published to production. A data audit log records changes to records: who updated a customer, who ran a bulk action, who triggered a refund. The first is about governance of the tool. The second is what an incident investigation needs.

Then ask the operational questions. How long is the log retained by default, and can that be extended. Can it be exported, and specifically can it stream to your SIEM rather than being downloaded by hand. Are reads logged or only writes, which matters if the data is regulated. Can an administrator delete or edit log entries, because a log that admins can rewrite is not evidence.

Where the data actually lives and runs

Two questions that sound similar and are not. Where is the data stored, and where is the query executed.

A platform that copies your production database into its own store has created a second copy of regulated data in a location your legal team has not reviewed, plus a synchronisation problem. A platform that queries your database in place holds credentials but not records. The second is a much shorter conversation with a data protection officer, and it is worth establishing early because it is architectural rather than configurable.

Then ask which region the platform runs in and whether that is a choice or a default, what subprocessors touch the data, whether a data processing agreement is available without a negotiation, and whether database credentials are stored encrypted and where the encryption keys live. For teams under GDPR, the transfer question is the one that generates the most paperwork, so raise it in week one rather than week six.

Shadow IT is a permissions problem, not a policy problem

Low-code platforms are bought to let non-engineers build things, and the same property is what creates shadow IT. A memo does not fix it. Two product features do.

The first is a separation between who can build and who can publish. If any builder can push an app to production, governance is a convention. If publishing requires a role that a small group holds, it is a control. The second is restricting which data sources a builder can reach. A builder who can connect any new database or API can route company data anywhere, and no review catches it because no review ever sees the app.

Ask whether both exist, and whether an administrator can see a list of every app in the account, who owns it, what it connects to, and when it last ran. That inventory is the difference between governance and hope.

Certifications, and what they do not tell you

SOC 2 Type II and ISO 27001 say the vendor operates a controls programme and had it examined. They do not say the product enforces row-level access, or that audit logs export to your SIEM, or that offboarding is automatic. Those are product questions and the certification does not answer them.

Use the certification as a filter and the checklist as the review. For how these questions land with enterprise buyers specifically, see the enterprise overview. Ask for the current report under NDA rather than the badge on the website, check the report date, and read the scope section to confirm it covers the product you are buying rather than the corporate systems around it. For anything involving health data in the United States, ask directly whether the vendor signs a business associate agreement, because that is a contractual commitment and not a feature.

The checklist

Twenty questions, in the order they tend to matter. Send them as they are.

Identity and access. 1. SAML or OIDC, and which identity providers are tested. 2. Is SCIM provisioning and deprovisioning supported. 3. Can local password login be disabled once SSO is enabled. 4. Are directory groups mapped to platform roles automatically. 5. Is session length configurable, and is multi-factor authentication enforceable. 6. How are API tokens issued, scoped, rotated and revoked.

Data access. 7. Are permissions enforced at row level or only at screen level. 8. Is that enforcement applied to the platform's own API as well as its interface. 9. Can a builder bypass a permission by duplicating a page or component. 10. Is the production database queried in place or copied into the platform.

Auditing. 11. Is there a builder audit log and a separate data audit log. 12. What is the default retention and can it be extended. 13. Can logs stream to a SIEM. 14. Are read events logged. 15. Can an administrator alter or delete log entries.

Deployment and governance. 16. Which regions are available and is region a choice. 17. Is a data processing agreement available without negotiation, and who are the subprocessors. 18. Is publishing to production a separate permission from building. 19. Can administrators restrict which data sources builders may connect. 20. Is a current SOC 2 Type II report available under NDA, and what is its scope and date.

How Jet Admin answers these

Worth saying plainly, since the point of the list is that vendors should answer it rather than describe risks.

Jet Admin is an internal tools builder built around this list. Permissions are enforced on rows, not only on screens, which is the control that makes external-facing portals possible in the first place. Apps run on the database you already have rather than on a copy, so production records stay where your policies already cover them. SAML SSO works with Google, Okta and Active Directory, with two-factor authentication available, and an activity log records what changed. Separate development, staging and production environments keep publishing distinct from building. Deployment can be cloud, self-hosted inside your own network, or hybrid, where the interface is hosted and the connection to your data is not. The trade-offs between those three are covered in the guide to on-premise low-code deployment.

On plans, granular permissions, SSO and audit logs are on the Business plan at $100 a month, and on-premise deployment sits in Enterprise. Prices checked in September 2026.

The honest gap: SCIM provisioning is the question worth putting in writing during evaluation rather than assuming from the SSO line, and that advice applies to every vendor on your shortlist including this one.

Running the review

Send the twenty questions before the demo, not after. A vendor who answers in writing has a product that does these things; a vendor who wants to "walk you through it on a call" usually has some of them. Then run the ten-minute row-level test yourself during the trial, because it is the one answer you should not take on trust.