SAP HANA Database Security: Secure users, encryption, auditing and network access

SAP HANA sits underneath S/4HANA, BW/4HANA and many custom applications, so a database superuser left active, an unencrypted backup or a technical user with critical privileges exposes every business record above it. The SAP NetWeaver and S/4HANA Basis Hardening Guide covers the ABAP application stack; this guide covers the database layer for on-premise and privately hosted SAP HANA 2.0: users and roles, the SYSTEM user, technical users, authentication options, data volume, log and backup encryption, TLS, network isolation and audit policies. It is written for SAP HANA database administrators, Basis teams and the security engineers who review them. Parameter names and defaults vary by support package stack (SPS), so confirm them against the security guide for your release.

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

Key takeaways

• Start with SAP's security baseline. SAP's guide opens with four actions: change the secure store master keys, assign critical privileges only to trusted users, protect internal communication channels, and apply the latest SAP HANA and operating system security patches.
• Every tenant has its own SYSTEM superuser. Create named administrators with only the privileges they need, then deactivate SYSTEM in the system database and in every tenant, keeping its credentials for emergencies.
• Encryption is switched on per database. Data volume, redo log and backup encryption are enabled separately for the system database and each tenant, so check every database, not just one.
• Enforce TLS and raise the minimum version. Setting sslEnforce to true refuses non-TLS SQL connections, and the documented default minimum protocol version is TLS 1.0, which most policies will want raised.
• Audit the system database too. Audit policies are defined per database; policies that exist in tenants do not cover administration done in the system database, so create policies there as well.

How identity and access work in SAP HANA

SAP HANA 2.0 runs as a multitenant database container: one system database and one or more tenant databases. Each tenant has its own users, catalog and logs, and its own SYSTEM superuser. The system database holds the DATABASE ADMIN system privilege for administering tenants. Cross-database access is off by default.

Tenant isolation

Isolation is low by default, which means tenant processes run under the same operating system user. High isolation runs each tenant's processes under a dedicated operating system user and group, which must exist for every tenant. Choose high isolation where tenants belong to different business units or data owners. The configuration change blocklist (multidb.ini) restricts which system properties tenant administrators can change, so that a tenant administrator cannot weaken settings controlled centrally.

Authentication options

For named people, prefer Kerberos or SAML so that MFA and leaver processes sit in the directory or identity provider. For technical users, prefer certificates over passwords where the client supports them.

Privileges and roles

SAP HANA grants access through five privilege types: system privileges (administration such as user management, backups and auditing), object privileges (SELECT, INSERT and others on schemas, tables and views), analytic privileges (row-level access to analytic views), package privileges (repository packages) and application privileges (XS applications). Privileges are bundled into roles: catalog roles created at runtime, design-time roles deployed as repository or HDI artefacts, and predefined catalog roles. SAP's own advice is to assign critical privileges only to trusted users and to avoid critical privilege combinations. Design-time roles are preferable for anything beyond administration, because they are transportable, versioned and cannot be granted by an administrator outside the deployment process. See the Database Credential and Access Security Guide.

Admin roles and privileged access

Locking down the SYSTEM user

SYSTEM is the initial superuser in the system database and in each tenant. SAP's guide includes a section on deactivating the SYSTEM user. A sound sequence:

1. Create named administrators: one per person, holding only the system privileges their duties need, such as USER ADMIN, ROLE ADMIN, BACKUP ADMIN or AUDIT ADMIN, ideally through roles.
2. Prove they work: test each administrative task with the named accounts, including restoring a backup and managing audit policies.
3. Deactivate SYSTEM: deactivate the SYSTEM user in the system database and in each tenant, using the statement given in the "Deactivate the SYSTEM User" section of SAP's security guide.
4. Vault the credentials: keep the SYSTEM passwords in a privileged access vault with dual control. A user with USER ADMIN can reactivate SYSTEM for an emergency.
5. Alert on reactivation: include user changes to SYSTEM in an audit policy and alert on any activation or connection.

Separating duties

Use a privileged access management tool to broker administrative sessions where possible, and record them. Operating system access to the HANA host (the <sid>adm user) is equally privileged: it can read secure stores and configuration files, so manage it under the same controls. See the Privileged Access Management Guide and the Unix and Linux Privileged Access Guide.

Integrations, API tokens and service accounts

Most connections to SAP HANA are made by technical users: the ABAP application server's schema user, ETL and replication tools, reporting services, monitoring agents and backup tools. These are the database's non-human identities.

• Restricted users for applications: SAP HANA supports restricted users, which start with no privileges and cannot create objects, as a basis for application users that should only do what their roles allow. Use them for reporting and integration accounts.
• Disable password lifetime only deliberately: technical users often have password expiry disabled so that jobs do not fail. Where that is necessary, compensate with long random passwords, rotation through a vault and alerts on interactive use.
• Use the secure user store: on clients and application servers, store connection credentials in hdbuserstore rather than in scripts, and change its master key as SAP's baseline advises.
• Prefer certificates and tickets: X.509, SAML, JWT and SAP logon tickets avoid static passwords for many integrations.
• Inventory and own: record every technical user, its purpose, owner, source host and privileges, and review it each quarter.

See the Service Account Security Guide and the Secrets Management Guide.

Logging and detection

SAP HANA auditing is defined per database through audit policies. Key points from SAP's guide:

• Per database: actions in the system database and in each tenant are audited individually. Policies created in tenants do not cover administration done in the system database, so create system database policies too.
• Audit trail targets: tenant audit trails go by default to a database table local to that tenant, and tenant administrators cannot change the target by default. If the target is syslog, each entry carries a Database Name field so tenants can be told apart.
• Protect the trail: forward audit entries to a SIEM or syslog collector that database administrators cannot alter, and keep audit administration separate from user administration.

What to audit

See the Database Audit Log Detection Guide for detection patterns that apply across database platforms.

Metrics

• SYSTEM status: number of databases where SYSTEM is active (target zero outside maintenance).
• Encryption coverage: percentage of databases with data volume, log and backup encryption enabled.
• Critical privilege holders: count of users with USER ADMIN, ROLE ADMIN, AUDIT ADMIN or DATABASE ADMIN.
• Audit coverage: percentage of databases with active policies, including the system database, forwarding to the SIEM.
• Patch currency: days behind the latest SAP HANA revision with security fixes.

Hardening baseline

Encryption

Data and log volume encryption stop anyone with operating system access to the volumes from reading data and redo log entries; backup encryption stops unauthorised parties from reading backups. Each is enabled per database. Root keys are held in the secure store (the instance SSFS or the Local Secure Store), and SAP's guide covers root key backup. Back up root keys separately from the data backups, because an encrypted backup cannot be restored without them. See the Database and Storage Encryption Guide.

TLS and network

SAP's guide documents these TLS settings in the communication section of global.ini:

The communication properties are on the default change blocklist and must be changed from the system database. SAP warns that if TLS is enforced you cannot connect to the system database without TLS, so prepare client certificates first. On the client side, ODBC's encrypt property defaults to false and must be set; sslHostNameInCertificate set to * skips host name validation, so use the real host name. SAP recommends storing certificates in in-database certificate collections rather than PSE files.

For networks, isolate internal communication channels with network zones and firewalls, and bind them to dedicated interfaces in multi-host and system replication setups; on single-host systems internal ports bind to localhost by default. Expose SQL ports only to application servers and administration networks. The system database's SQL port follows the pattern 3<instance>13; tenant SQL ports are assigned per tenant, so derive the list from your system rather than assuming it.

Passwords and patches

Set the password policy in the password policy section of indexserver.ini, including minimal_password_length and maximum_invalid_connect_attempts, to match your standard, and apply it in every tenant. Change the master keys of the instance SSFS, the system PKI SSFS and hdbuserstore after installation, as SAP's baseline advises. Apply SAP HANA revisions and operating system security patches promptly through the SAP security patch process. See the Patch Management Guide.

Rollout and rollback

1. Assess: list databases, SYSTEM status, encryption state, TLS settings and audit policies.
2. Pilot in non-production: enable encryption, TLS enforcement and audit policies on a sandbox, and test application connections.
3. Roll to production by database: one tenant at a time, after a verified backup and root key backup.
4. Roll back: TLS enforcement can be reversed by setting sslEnforce to false from the system database; keep the root key backup available before any encryption change.

Common misconfigurations

• SYSTEM active in tenants: deactivated in the system database but left active in tenants created later. Make deactivation part of tenant creation.
• Encryption on one database only: data volume encryption enabled for the main tenant but not for the system database, a newer tenant or backups.
• No root key backup: encrypted backups that cannot be restored after a host loss.
• Audit policies only in tenants: system database administration goes unrecorded.
• Technical users with critical privileges: integration accounts granted USER ADMIN or broad schema rights during a project and never reduced.
• TLS 1.0 minimum left at default: the documented default is kept although policy requires TLS 1.2.

Framework mapping

Practitioner checklist

• Create named administrators with least-privilege roles, then deactivate SYSTEM in the system database and every tenant.
• Separate user administration, audit administration, backup and key management across different people.
• Enable data volume, log and backup encryption in every database and back up root keys separately.
• Set sslEnforce to true, raise sslMinProtocolVersion and set encrypt on clients.
• Choose high tenant isolation where tenants have different data owners.
• Create audit policies in the system database and each tenant and forward them to a SIEM.
• Inventory technical users with owners, use restricted users and store client credentials in hdbuserstore.
• Change SSFS and secure user store master keys after installation.
• Apply SAP HANA revisions and operating system patches through a defined patch cycle.

Standards and references

• SAP: SAP HANA Security Guide for SAP HANA Platform (SPS05 edition; check the SAP Help Portal for the edition matching your revision)
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0
• ISO: ISO/IEC 27001:2022 Information security management systems
• CIS: Critical Security Controls v8.1
• MITRE ATT&CK: T1078 Valid Accounts

Related NHI Mgmt Group resources: SAP NetWeaver and S/4HANA Basis Hardening Guide · Database Security Guide · Database and Storage Encryption Guide · SAP Identity and Access Security Guide