Data Security

Audience: System/Security Administrators, Low-code Engineers

Skill Prerequisites: System Administration and Maintenance

This page describes how data is protected in a Plant an App installation: where it's stored, how it's encrypted at rest and in transit, how certificates are used, and how connections to other systems are secured.

It applies to on-premises and private-cloud installations, where you run Plant an App on your own servers. In those installations, you control the servers, the database and the network, so some protections are configured by you. They're marked You configure below.

Where Data Is Stored

Data	Location
Application data: entities, form submissions, listings, workflow and job history, logs, configuration	The Microsoft SQL Server database of the installation
Files: uploads, generated documents, exports	The file storage you choose for each folder: local disk, a network share, or cloud storage such as Amazon S3 or Azure Blob Storage. See File Storage.
Connector secrets: API keys, passwords, tokens	The application database, encrypted (see Connector secrets)
Data in other systems	Stays in those systems. Plant an App reads or writes it only when an action, listing or token calls them. See Connecting to Oracle, Db2 and Other Databases.

In an on-premises or private-cloud installation, all of this stays on your infrastructure. Plant an App sends data to an external service only when an application is built to call one, for example with Server Request, an AI add-on or an email connector.

File Storage

Files are kept in folders, and each folder has a folder type that decides where its files are stored. You can mix them: for example, keep most folders on the network share and send large archives to cloud storage. Manage folder types in File Management > Manage Folder Types.

Storage	Where the files are	Typical use
Local disk	The site folder on the web server. Three built-in folder types: Standard (plain files), Secure (files are renamed so they can only be downloaded through the site, with folder permissions checked) and Database (files are saved in the SQL Server database).	A single web server
Network share	The whole site folder is on shared storage, reached by an SMB (UNC) path: a clustered file server, a NAS or SAN, DFS, or a cloud file service such as Amazon FSx or Azure Files. Every web server uses the same files. The built-in folder types work as on a local disk.	Several web servers, and the shared storage that government and enterprise data centers usually provide. See Performance, Scalability and High Availability.
Amazon S3	An S3 bucket, through an S3 folder type. Needs the S3 storage add-on.	Large or fast-growing files, cloud storage. See Amazon S3 Storage Integration.
Azure Blob Storage	A container in an Azure storage account, through an Azure folder type (account name, account key, container).	Large or fast-growing files, in Azure

Users and actions work with every folder the same way, whatever its type.

Encryption of files at rest. You configure. Encrypt the storage the files live on:

• Local disk and network share: BitLocker, or the volume encryption of your file server, SAN or private cloud. The Database folder type is covered by the database's Transparent Data Encryption.
• Amazon S3: objects are encrypted at rest by default with server-side encryption (AES-256). See AWS's Protecting data with encryption.
• Azure Blob Storage: data is always encrypted at rest with 256-bit AES. See Microsoft's Azure Storage encryption for data at rest.

Encryption at Rest

Database: Transparent Data Encryption (AES-256)

You configure. SQL Server Transparent Data Encryption (TDE) encrypts the database files, the transaction log and the backups with AES-256. It's transparent to the application, so Plant an App needs no changes. Turn it on in SQL Server. TDE is available in SQL Server Enterprise edition, and in Standard edition from SQL Server 2019. See Microsoft's Transparent data encryption guide.

You can also encrypt the server disks with BitLocker, or with your private cloud's volume encryption.

Backups

You configure. With TDE, backups are encrypted too. Without TDE, use SQL Server backup encryption with AES-256. Protect the certificate and keep a copy of it outside the server, or the backups can't be restored.

Connector secrets

Connector values such as passwords, API keys and tokens are encrypted with AES-256 before they're saved. The key belongs to the installation. In the connector editor, secret values are shown as ******. Use Connector Encrypt to encrypt a value the same way from an action.

Store secrets in connectors, not in action parameters or tokens.

Form and listing state

Data that Plant an App sends to the browser and receives back, such as the state of dynamic forms and the tickets in auto-login links, is encrypted with AES-256. The key is derived with PBKDF2 from the installation's machine key. The browser only receives the encrypted value, so it can't read the data.

Encrypting Application Data (AES-256)

Applications can encrypt sensitive fields themselves before they're saved, for example a national ID number or a bank account:

Action	What it does
AES Encrypt / AES Decrypt	Symmetric encryption with AES-256 (also AES-128 and AES-192), CBC mode, PKCS#7 padding. You choose the key.
RSA Encrypt / RSA Decrypt	Public-key encryption. Anyone with the public key can encrypt, and only the private key can decrypt. Use keys of 2048 bits or more.
Generate RSA Keys	Creates an RSA key pair. Choose 2048 bits or more.

See Security actions for when to use each one. Passwords should never be encrypted with these actions. Let the platform's user management handle them.

Encryption in Transit

Browser to server (HTTPS / TLS)

You configure. Plant an App runs on IIS. Install a TLS certificate on the website (or on the load balancer in front of it), and turn on SSL Enabled and SSL Enforced in the site settings, so every page is served over HTTPS.

We recommend:

• TLS 1.2 or later only. Disable SSL 3.0, TLS 1.0 and TLS 1.1 in Windows (SCHANNEL).
• A certificate from a trusted certificate authority, or from your organization's PKI.
• If TLS ends at a load balancer, encrypt the connection from the load balancer to the web servers too, unless they're on an isolated network.
• An HSTS header, set in IIS or at the load balancer.

Server to database

You configure. Encrypt the connection between the web servers and SQL Server with TLS. Install a certificate on SQL Server and add Encrypt=True to the connection string in web.config. Use TrustServerCertificate=True only for testing. See Microsoft's Configure SQL Server Database Engine for encrypting connections.

For Oracle and Db2, use the network encryption options of their drivers. See Connecting to Oracle, Db2 and Other Databases.

Server to other systems

• Server Request calls other systems over HTTPS. Enforce SSL rewrites http URLs to https.
• OpenID Connect login requires HTTPS by default.
• Upload to FTP supports FTPS.
• LDAP connections to Active Directory or OpenLDAP aren't encrypted unless you use LDAPS. See those pages.

Certificate-Based Security

Use	How
HTTPS for users	A TLS certificate on IIS or on the load balancer.
Mutual TLS to other systems	Server Request can send a client certificate from the server's certificate store, selected by thumbprint (Enterprise).
Reading a caller's certificate	Get Client Certificate Details reads the client certificate a caller presented.
Single sign-on	With OpenID Connect, tokens are validated against the identity provider's signing keys, issuer and audience.
Passwordless login	Passkeys (FIDO2 / WebAuthn): only the public key is stored on the server.
Public-key encryption of data	RSA Encrypt / RSA Decrypt.
Document signatures	Sign PDF, with the user's own certificate.

Access to Data

• Users and roles. Access to pages, forms, listings and actions is controlled with roles.
• APIs. Each API endpoint is Public, Private, or protected with API keys or JWT with OAuth scopes. Send API keys in the Authorization header, not in the URL, so they don't end up in logs.
• Input sanitization. Secure Input removes scripts and unsafe HTML from user input, to prevent cross-site scripting.
• SQL. In Run SQL Query, pass values with Bind Tokens, so they're sent as parameters.
• Database account. Run the application with a SQL user that has only the rights it needs. See Defining the SQL user.

Checklist for a New Installation

#	Item	Where
1	TLS certificate on the website, SSL Enforced on	IIS, site settings
2	Only TLS 1.2 or later enabled	Windows Server (SCHANNEL)
3	TDE on the application database	SQL Server
4	Encrypt=True in the database connection string, certificate on SQL Server	web.config, SQL Server
5	Backup encryption, certificate copied to a safe place	SQL Server
6	Least-privilege SQL user	SQL Server
7	Secrets only in connectors	Connectors
8	APIs protected with API keys or JWT	API endpoints
9	Access to web.config and the server restricted to administrators	Windows Server

Revised 11/05/2026