Qlik Sense Security: Section Access, Spaces, API Keys and Windows Server Hardening

Qlik Sense apps load whole datasets into memory, so who can open an app, which rows and fields each user sees, and how well the server itself is locked down decide whether sensitive data stays where it belongs. This guide covers the customer side of Qlik Sense security in both deployment models: Section Access data reduction, shared and managed spaces and security roles in Qlik Cloud, API keys, and security rules, administration roles, certificates and server hardening in Qlik Sense Enterprise on Windows (QSEoW). It is written for Qlik administrators, BI platform owners and security engineers. For data protection principles that apply to every analytics platform, see the Data Security Guide.

This is an independent guide from NHI Mgmt Group, based on Qlik's public documentation as of November 2026. It is not sponsored or reviewed by Qlik. Product features change, so confirm settings against Qlik's current documentation.

Key takeaways

• Section Access is strict exclusion. Users not listed in the security table cannot open the app, values are matched in upper case, and data is reduced at load, so test every table change with a USER level account before publishing.
• Spaces are the Qlik Cloud permission boundary. Use managed spaces for published production apps, give most people Can view, and keep Owner and Can manage to a few named people.
• Keep Tenant Admin and RootAdmin rare. Tenant Admin can be granted access to all users' content, including personal spaces; Analytics Admin, Data Admin and QSEoW's SecurityAdmin, ContentAdmin and AuditAdmin cover most duties.
• Govern API keys centrally. Restrict Manage API keys to a custom role, set a maximum token expiration and a per user key limit, and revoke keys immediately when activity looks wrong.
• Harden QSEoW at the OS and proxy. Use a dedicated service account, open only required ports, put a trusted certificate on the Qlik Sense Proxy, set protocol and cipher policy in Windows and apply Qlik updates promptly.

How identity and access work in Qlik Sense

Qlik separates authentication from authorisation, and authorisation itself has two independent layers: access control (which apps, spaces or streams a user can reach) and data reduction (which rows and fields they see inside an app, through Section Access). A user who passes access control can still see nothing in an app if Section Access excludes them, and an app opened by the wrong audience exposes everything unless Section Access is in place.

Section Access done well

Section Access is a section of the load script, separate from Section Application, holding a security table with system fields. Rules can come from an inline table or from a database or spreadsheet loaded like other data.

• ACCESS: ADMIN or USER. ADMIN sees all data unless the table restricts it; USER sees only what the table allows. A USER whose reduction value matches nothing cannot open the app.
• USERID, USER.EMAIL and GROUP: identify the user. In Qlik Cloud, USERID matches the identity provider subject claim (check it by appending /api/v1/diagnose-claims to the tenant URL); USER.EMAIL is the portable choice when the same app runs in both models. GROUP uses identity provider or custom groups according to the QlikCloudGroupMode variable.
• Reduction fields: user defined fields whose upper case names match fields in the data model; matching values are kept and the rest are hidden. Qlik advises against several reduction fields, because combinations can grant unintended access.
• OMIT: hides named fields from a user. Do not use it on key fields.
• Upper case: all Section Access names and values are converted to upper case, so wrap lower case source fields in Upper().
• Wildcards: * in a reduction column means all values listed in the table, not all values in the data; * in USERID or GROUP means everyone. A * in USER.EMAIL admits all authenticated users, so use it deliberately.

Operational points from Qlik's documentation: changes take effect only after a reload; list the people who edit and reload the app with ADMIN access; in managed spaces, reload and republish the source app; remove attached files before publishing, because Section Access restrictions do not follow copies; avoid colour assignments on master dimension values for sensitive data; and do not reuse system field names in the data model. Optimised QVD loads do not apply with Section Access, so add a transformation such as Upper() or WHERE 1=1. Settings that rely on PASSWORD, NTSID or NTDOMAINSID belong to QSEoW and are replaced by identity provider claims in Qlik Cloud.

Admin roles and privileged access

Qlik Cloud

• Tenant Admin: full control of the tenant. Qlik warns that holders may be granted access to content, including personal content, for every user. Assign it to a small named group and review quarterly. A tenant admin cannot remove their own role, so a second admin is needed to change it.
• Analytics Admin and Data Admin: narrower administration of governance and content areas or of data spaces. They cannot manage users or open other users' personal spaces, which makes them the default for day to day administration.
• Audit Admin: review of Natural Language API usage and assistant conversations. Give it to the security or compliance team.
• Space creator roles: Shared Space Creator, Managed Space Creator and Data Space Creator control who can create new permission boundaries; restrict Managed Space Creator to the BI governance team.

In shared spaces, Owner and Can manage handle membership, Can edit adds app content, Can edit data in applications also edits load scripts and business logic, Can view only views, and Can consume data uses data sources. Load script editing is the sensitive right, because the script defines Section Access, so grant Can edit data in applications sparingly.

Qlik Sense Enterprise on Windows

Review the default Everyone stream, where all users have read and publish rights by default: narrow publish rights with security rules so only approved publishers can place apps in front of the whole organisation. Built-in INTERNAL accounts beginning sa_ are reserved for services and cannot sign in interactively.

Integrations, API tokens and service accounts

Qlik Cloud API keys

API key settings sit in the Administration activity center, Settings, Security tab. Users need a custom role with the Manage API keys permission to generate keys, so assign it only to integration owners.

• Change maximum token expiration: set a short ceiling for new keys (NHI Mgmt Group advice: 30 to 90 days); existing keys keep their original expiry.
• Change maximum of active API keys per user: keep it low; the ceiling is 1000.
• Revoke: keys show Active, Expired or Revoked. Revocation is immediate and cannot be undone; find the key ID in Events, then revoke it in the API keys section.
• Handling: Qlik's guidance is to keep keys out of public repositories, regenerate them regularly, monitor usage and grant only the roles and OAuth scopes required, protecting API credentials as carefully as administrator credentials.

A key acts as the user who created it, so generate integration keys from dedicated service users with narrow roles rather than from administrators. See the API Key Management Guide.

Data connections

In Qlik Cloud only the connection owner can edit a connection, and must re-authenticate after each edit; owning it grants nothing beyond the owner's space role. If the owner leaves the tenant, dependent apps stop refreshing until a tenant admin reassigns ownership, so give production connections to a service user. In QSEoW, connection strings and passwords are encrypted with AES-256, and the service account needs full control of the data connection folders it reads. Use read only database accounts for every connection.

QSEoW service account and certificates

• Service account: run Qlik services under a dedicated domain account with full control of the shared folder, the installation directory, %ProgramData%\Qlik and data connection folders. Local administrator rights are not required if you configure bootstrap mode as Qlik describes. For Group Managed Service Accounts, Qlik describes installing with a standard account and then switching the service log-on to the gMSA; test this, as some features such as Active Directory user directory connections may need adjustment. See the Group Managed Service Accounts (gMSA) Guide.
• Certificates: Qlik Sense acts as an internal certificate authority and issues certificates for component trust. The default proxy certificate is not meant for production user access: apply a trusted certificate to the Qlik Sense Proxy, or terminate TLS at a load balancer that trusts the internal one. Protect exported certificates used by integrations, since certificate trust authorises external components.
• Authentication modules: ticket, session and header solutions depend on a trusted front end. Accept headers only from the proxy or gateway that sets them, over TLS.

Logging and detection

QSEoW records repository changes and who made them, writes audit and security logs through its logging framework with central storage and an injection resistant format, and signs licence logs. The QMC audit view is available to AuditAdmin. In Qlik Cloud, the Events view in the Administration activity center is where Qlik directs administrators to look for suspicious API key activity. Forward both into your SIEM.

Metrics to track: number of Tenant Admin and RootAdmin holders; share of sensitive apps with Section Access tested by a USER account; API keys older than your maximum expiry (target zero); production apps in managed spaces; QSEoW nodes on the current release; days since last space membership review.

Hardening baseline

1. Identity: connect your identity provider and, on QSEoW, choose SAML, OIDC or Kerberos virtual proxies over anonymous access.
2. Admin roles: limit Tenant Admin and RootAdmin; use Analytics Admin, Data Admin, SecurityAdmin, ContentAdmin and DeploymentAdmin for daily duties.
3. Spaces and streams: publish production apps to managed spaces or controlled streams; restrict publish rights on the Everyone stream.
4. Section Access: apply it to every app with personal or restricted data; prefer GROUP or USER.EMAIL driven tables loaded from a governed source.
5. API keys: custom role for Manage API keys, short maximum expiry, low per user limit, service users for integrations.
6. QSEoW network and TLS: open only the ports your architecture needs, put a trusted certificate on the proxy, disable deprecated protocols and ciphers in Windows (Qlik inherits them from the OS), and add HSTS, X-Content-Type-Options, X-Frame-Options and Content-Security-Policy under Additional response headers on the virtual proxy.
7. QSEoW host: dedicated service account, Qlik's recommended antivirus exclusions with compensating monitoring, restricted PostgreSQL connections and encrypted database traffic in multi-node sites.
8. Patching: apply Qlik Sense Enterprise on Windows patches and releases promptly using Qlik's release notes, and follow Qlik's product security and vulnerability policy for advisories.

Testing and rollback: Qlik warns that aggressive server hardening can break a deployment, so take a backup first and change one control at a time. Test response headers in a new virtual proxy before applying them to the main one, because a bad header can lock users out. For Section Access, keep an ADMIN entry for app maintainers and reload in a copy of the app before publishing.

Common misconfigurations

• Lower case mismatches: reduction values loaded in lower case never match the upper cased Section Access values, so users are locked out or apps are opened without the intended reduction during troubleshooting.
• Wildcard misunderstanding: assuming * in a reduction column means all data, when it means all values listed in the security table.
• Broad Everyone stream: the default read and publish rights left unchanged, so any user can publish an app to everyone.
• Personal data connections in production: a departed employee owns the connection and refreshes stop, or their personal credential keeps feeding a shared app.
• Admin generated API keys: integration keys created by a Tenant Admin with long expiry, carrying full tenant rights.
• Default proxy certificate in production: users trained to click through certificate warnings.

Framework mapping

Practitioner checklist

• List every Tenant Admin, RootAdmin and SecurityAdmin holder and reduce to a named few.
• Move production apps into managed spaces or controlled streams and restrict Everyone stream publishing.
• Apply Section Access to apps with restricted data, convert values with Upper() and test with a USER account.
• Grant Can edit data in applications only to people who own load scripts.
• Restrict Manage API keys to a custom role, set maximum expiry and per user limits, and issue keys from service users.
• Reassign production data connections to service users with read only database accounts.
• On QSEoW, run services under a dedicated account, apply a trusted proxy certificate and set OS cipher policy.
• Add security response headers on a test virtual proxy, then roll out.
• Forward Events, QMC audit and proxy security logs to the SIEM and alert on admin role and API key changes.
• Apply Qlik updates promptly and record the release level of every QSEoW node.

Standards and references

• Qlik: Qlik Sense Enterprise on Windows security
• Qlik: Managing data security with Section Access
• Qlik: Managing API keys
• Qlik: Managing permissions in managed spaces
• Qlik: Permissions granted by security roles
• Qlik: Default administration roles
• Qlik: Qlik Sense Enterprise on Windows, securing and hardening server
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls

Related NHI Mgmt Group resources: Data Security Guide · API Key Management Guide · Least Privilege Techniques Guide · SAML Security Guide