Blog Post

Running SAP Applications on the Microsoft Platform
10 MIN READ

Securing SAP ABAP-to-HANA Authentication with Azure Key Vault Managed HSM (Hardware Security Module)

ZachM's avatar
ZachM
Icon for Microsoft rankMicrosoft
Oct 29, 2026

Protect SAP HANA database credentials by moving certificate private keys into Azure Managed HSM and eliminating portable authentication secrets.

Overview

Security is a critical consideration for any enterprise application landscape. One of the most common objectives of modern threat actors is the theft of portable credentials, such as passwords, keys, or certificates. This challenge is particularly relevant for SAP environments, where ABAP systems must connect to SAP HANA using either a password or an X.509 client certificate. While operating system controls can help mitigate the risk of theft, these underlying secrets remain portable assets that can be copied, exported, and potentially reused outside of the original system. For highly privileged HANA accounts, this creates a significant security concern.

To address this risk, Microsoft and SAP have collaborated on a solution that leverages Azure Key Vault Managed HSM to protect the private key used for SAP HANA certificate-based authentication. Rather than storing a portable private key on the application server, cryptographic operations are performed within the Managed HSM, ensuring that the private key never leaves the hardware security boundary.

By combining Azure Key Vault Managed HSM, Managed Identity, the Microsoft PKCS#11 driver, and SAP CommonCryptoLib (CCL), SAP customers can implement certificate-based authentication between ABAP and HANA while significantly reducing the risk of credential theft. Even if a PSE file is copied from the system, because it now only contains a pointer to the HSM, it cannot be used without access to the corresponding key stored in the Managed HSM.

Referenced Documentation

  1. Managed HSM Documentation Hub
  2. Managed HSM TLS Offload Library and its GitHub repository
  3. SAP Note 3521774

Architecture

The following diagrams illustrate the components required for this solution and the communication flow between them. 

This first diagram provides a high-level overview of the solution architecture. SAP application servers and the SAP HANA database are deployed within an Azure Virtual Network, while Azure Key Vault Managed HSM provides secure storage for the private key used during HANA client certificate authentication. The application servers authenticate to Managed HSM using a user-assigned managed identity and perform cryptographic operations through the Microsoft PKCS#11 library. The private key never exists on the operating system or within the PSE itself. Instead, the PSE contains the certificate and a reference to the key stored in Managed HSM. When the application server needs to authenticate to HANA, cryptographic operations are performed by the HSM on behalf of the application server, eliminating the need for an exportable private key. The blue arrows represent the communication paths used by the application servers to access both Managed HSM and SAP HANA.

The second diagram illustrates the runtime authentication flow. When an SAP application server initiates a connection to SAP HANA, SAP CommonCryptoLib loads the HSM-backed PSE and requests a cryptographic signature from Azure Managed HSM through the Microsoft PKCS#11 library. The certificate challenge is signed using the private key stored within the HSM, and the resulting signature is returned to the application server. SAP HANA validates the certificate and signature, completing the X.509 authentication process without exposing or exporting the private key.

Now that we've covered the architecture and authentication flow, let's walk through the end-to-end implementation, starting with the Azure components and then configuring the SAP application and database layers.

Prerequisites

Required Software Versions
  • SAP Common Crypto Library (CCL): Version 8.5.59 or higher
  • SAP S/4 HANA: 2025 or later
  • SAP Kernel: Version 9.16 or later
  • Azure Managed HSM TLS Offload Library: Version 1.1.0.03419 or later
  • Application Server OS: Refer to supported versions
Required Setup

This guide assumes you have the following setup:

  • SAP System deployed in an Azure Virtual Network.
  • SAP System with SSL enabled and enforced for system communication, with SSFS used to secure the HANA connection.
  • SAP HANA system with SSL/encryption enforcement for connections, and internal PSEs.
  • PKI infrastructure that is trusted by your systems, with the ability to sign certificates.
  • DNS setup to support Private Endpoints.

Implementation

The following instructions are intended for a test environment; please review the Production Considerations section before deploying this solution in production.

In this example our system's SID is NW1, adjust as needed for your environment

Azure Setup

  1. Deploy an Azure Managed HSM
    1. For testing, you can use 3 self-signed certs as described to activate your Managed HSM.  
  2. Create and assign a user-assigned managed identity(uMSI) to all your SAP application VMs
  3. Grant Managed HSM local RBAC role "Managed HSM Crypto User" to your uMSI and scope it to "all Keys"
  4. Deploy a Private Endpoint for your Managed HSM
    1. This should be deployed into a virtual network that is reachable by all SAP application servers and configured with the appropriate Private DNS resolution.

SAP Application Server Setup

Perform the following steps on all of your application servers.

  1. Download the latest RPM for the Managed HSM TLS Offload Library for your OS.
  2. Install the library and update the library cache
    sudo rpm -i <mhsmOffloadLibrary>.rpm
    sudo ldconfig
    
  3. Update the Managed HSM offload library config file located at: /etc/mhsm-pkcs11.conf
    1. A sample file is located at /usr/src/mhsm-pkcs11-<VersionNumber>/mhsm-pkcs11-template.conf with reference to all the available parameters.  Ensure that the parameters mentioned below are included.
      {
        "tokens": [
          {
            "slotid": 0,
            "protocol": "https://",
            "uri": "managedhsm.azure.net",
            "resourceName": "<mHSM name>",
            "resourceType": "mhsm"
          }
        ],
        "options": {
          "DisableTLSAuthentication": false
        },
        "msi": {
          "IdentityMSI": true,
          "enableIMDSCache": true,
          "MSIClientID": "<uMSI Client ID>"
        },
        "ConnectionCache": {
          "Disable": false,
          "MaxConnections": 20
        }
      }
  4. Test the connection to the Managed HSM by running the following command.  As long as you get a response and no errors then your configuration is good.
    sudo /usr/src/mhsm-pkcs11-<versionnumber>/samples/bin/mhsm_p11_display_info

PSE and Key Generation

Perform these steps on only one application server

  1. Create a new private key in the Managed HSM.  
    # Command
    mhsm_p11_create_key --identity --RSA 4K --label NW1_HANAAuth_01
    
    # Output
    Key is generated successfully.
    Managed HSM Key ID: https://<HSMName>.managedhsm.azure.net/keys/p11-2fb60eb9a7d44101bc7e9ab03289544d/699465522b174d02133fe2fa33c2af20
    Key Name: p11-2fb60eb9a7d44101bc7e9ab03289544d
  2. Add CCL and Managed HSM configuration options to your DEFAULT.PFL.  You can also use a dedicated profile for your CCL if you desire.
    #Set CCL Profile
    SETENV_90 = CCL_PROFILE=$(DIR_PROFILE)/DEFAULT.PFL
    
    #CCL HSM parameters for HANA Cert Auth PSE
    ccl/ccl_NW1_HANAAuth_01/hsm_type = pkcs11default
    ccl/ccl_NW1_HANAAuth_01/driver_path = /usr/lib/libmhsm-pkcs11.so
    ccl/ccl_NW1_HANAAuth_01/slot_name = slot: 0; Azure Cloud; <mHSMName>; mhsm
    ccl/ccl_NW1_HANAAuth_01/same_slot_name_index = 1
    ccl/ccl_NW1_HANAAuth_01/label_pub_key = NW1_HANAAuth_01
    ccl/ccl_NW1_HANAAuth_01/label_priv_key = NW1_HANAAuth_01
    ccl/ccl_NW1_HANAAuth_01/multi_thread = Yes
  3. Generate your PSE file.
    # You can also add these to your profile
    export CCL_PROFILE="/sapmnt/NW1/profile/DEFAULT.PFL"
    export SECUDIR="/usr/sap/NW1/D00/sec"
    
    /sapmnt/NW1/exe/uc/linuxx86_64/sapgenpse gen_hsm_pse -p /usr/sap/NW1/D00/sec/NW1HANAAuth.pse -x "" -y "" -f ccl_NW1_HANAAuth_01 CN="NW1HANAAuth.<YourDNSDomainName>"
    
  4. Export your CSR, sign it, and import the response.
    # Export CSR
    /sapmnt/NW1/exe/uc/linuxx86_64/sapgenpse gen_pse -p /usr/sap/NW1/D00/sec/NW1HANAAuth.pse -onlyreq
    # Save the output in a file, and submit it to your CA to sign
    # Import Response
    /sapmnt/NW1/exe/uc/linuxx86_64/sapgenpse import_own_cert -p /usr/sap/NW1/D00/sec/NW1HANAAuth.pse -c /root/certs/NW1HANAAuth.p7b
  5. Import all your PKI CA's to the PSE to establish trust.
    # Assuming you have all your CA's public certs in a single directory as .cer file.  Adjust as needed
    for file in /root/certs/*.cer; do
    /sapmnt/NW1/exe/uc/linuxx86_64/sapgenpse maintain_pk -a "$file" -p /usr/sap/NW1/D00/sec/NW1HANAAuth.pse
    done

     

HANA Database Configuration

All Certificate Subject names are case sensitive.  You must use the certificate subject exactly how it is displayed in the certificate.

  1. Ensure all your PKI CA's are imported in HANA.  They should already be populated for SSL, but here is an example of importing one CA.
    --For this example we will be using this public CA: 'CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US'
    --Replace <CertShortName> with an easy name you can use to identify your certificate, ie) "DigiCert-GR-G2"
    --Use the text of your base64 encoded .cer
    CREATE CERTIFICATE <CertShortName> FROM '-----BEGIN CERTIFICATE-----
    MIIHuDCCBaCgAwIBAgITMwAAABJ+c5NH51vhoQAAAAAAEjANBgkqhkiG9w0BAQwF
    ADBRMQswCQYDVQQGEwJVUzEeMBwGA1UEChMVTWljcm9zb2Z0IENvcnBvcmF0aW9u
    MSIwIAYDVQQDExlNaWNyb3NvZnQgVExTIFJTQSBSb290IEcyMB4XDTI1MDgxNDIz
    <SNIP>
    T85pMUZup9ZRlYcuqDSfH2r5cokDcwCKjarG8YrjKiQ9i3hLzRs2sQEG3wjf2lrb
    B99kBMBp4Ylf6v3t
    -----END CERTIFICATE-----
    ';
    
    CREATE X509 PROVIDER DigiCert_Root_Provider WITH ISSUER 'CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US';
    CREATE PSE X509_DigiCert_Root_PSE;
    ALTER PSE X509_DigiCert_Root_PSE ADD CERTIFICATE <CertShortName>;
    SET PSE X509_DigiCert_Root_PSE PURPOSE X509 FOR PROVIDER DigiCert_Root_Provider;
    
  2. Edit the user account for HANA to use certificate authentication.
    ALTER USER <APPUserName> ADD IDENTITY '<Full Exact Certificate Subject>' FOR X509 PROVIDER DigiCert_Root_Provider;

Enablement

On the application server where you created the PSE, perform the following

  1. Stop all SAP services.
  2. Update SSFS for database login.
    su - nw1adm
    
    # The rsecssfx command can't properly handle the characters in the connection string, so write them to a file first
    echo "HOST=<HANADBFQDN>:30015;TENANTDB=NW1;CON_PARAM=authenticationMethods=x509,authenticationX509=NW1HANAAuth.pse,ssltruststore=NW1HANAAuth.pse" > x509_conn.txt
    
    rsecssfx put DB_CONNECT/DEFAULT_DB_CON_ENV -valuefile x509_conn.txt -valuefile7bit -plain
    rsecssfx put DB_CONNECT/DEFAULT_DB_PASSWORD "" -plain
  3. Test connectivity to the database.
    hdbsql -n <HANADBFQDN>:30015 -sslprovider commoncrypto -ssltrustcert \
        -Z authenticationMethods=x509 -Z authenticationX509=NW1HANAAuth.pse \
        -Z ssltruststore=NW1HANAAuth.pse -Z sslkeystore=NW1HANAAuth.pse -Z ENCRYPT=true \
        -j "SELECT current_user FROM DUMMY;"
    
    #Expected Output
    CURRENT_USER
    -------------------
    <APPUserName>
  4. Once Connectivity is verified, copy the PSE file to all of the application servers, and perform the enablement steps again.
  5. You can now start the SAP system.
  6. Verify inbound connections are using X509 auth on HANA.
    SELECT USER_NAME,CLIENT_HOST,CLIENT_IP,IS_ENCRYPTED,AUTHENTICATION_METHOD,COUNT(*) FROM M_CONNECTIONS WHERE USER_NAME = 'SAPHANADB' and CONNECTION_STATUS != '' group by USER_NAME,CLIENT_HOST,CLIENT_IP,IS_ENCRYPTED,AUTHENTICATION_METHOD

     

Troubleshooting Tips

If you are running into errors during your implementation, you can enable logging on both the TLS Offload Library and the SAP CCL.  If you are having issues connecting to the Managed HSM, or performing any certificate operations, then the Managed HSM logs and the TLS Offload Library logs will be of use to you.  If you are experiencing issues connecting or logging into HANA then the CCL logs are a good place to look for any auth errors.

Logs for TLS Offload Library

Add the following to the end of your /etc/mhsm-pkcs11.conf file.  Ensure that the processes have write access to the path you specify, then restart SAP.  A sample file is located at /usr/src/mhsm-pkcs11-<VersionNumber>/mhsm-pkcs11-template.conf with reference to all the available parameters.

{
[...]
    "log": {
        "directory": "/var/log/mhsm",
        "module": {
            "P11Interfaces": true,
            "FunctionLevelTrace": true,
            "curl": {
                "Level": "Off",
                "DisplayAsHex": false
            }
        },
        "flags": {
            "SendToFile": true,
            "IncludeProcessId": true,
            "IncludeThreadId": true,
            "IncludePINs": false
        }
    }
}

CCL Logs

You can refer to SAP Note 2491573 for more detailed options, but the critical steps are here:

  1. Update Default.PFL with the below options,
    # Ensure sidadm has write access to the selected directory
    ccl/trace/directory = /var/log/scctrace
    # 0:Deactivated, 1:Errors, 2:Warnings, 3:Info, 4:Developer
    ccl/trace/level = 4
    # Adjust these parameters based on your size and workload
    ccl/trace/rotatefilenumber = 50
    ccl/trace/rotatefilesize = 10000000
  2. Add the following to your sidadm profile (/usr/sidadm/.cshrc file)
    [...]
    setenv CCL_PROFILE /sapmnt/<SID>/profile/DEFAULT.PFL
    setenv SECUDIR /usr/sap/<SID>/D00/sec/
  3. Restart your Instance

Production Considerations

  1. For a Production environment you will need to establish your security domain for Azure Managed HSM.  Consult with your internal security and compliance teams for your organization's requirements.
  2. Review the following to properly secure your Managed HSM
  3. With this setup, Managed HSM is now crucial to the operation of your SAP system.  If the Managed HSM is unavailable, application servers will no longer be able to authenticate new sessions to HANA.  Review Managed HSM disaster recovery and Managed HSM backup and recovery to determine the business continuity and disaster recovery (BCDR) strategy that best meets your organization's requirements.
  4. HSM performance and how many SAP systems can one Managed HSM support.
    1. For performance information see managed HSM scaling guidance. The Sign operation is the primary cryptographic operation used by this authentication flow.
    2. Due to the many differences and customizations possible in SAP, we are unable to provide guidance on how many systems can be supported.  This will vary based on system size, load, and any custom code you may have.  You will have to perform your own load testing to determine the load your system(s) put on the HSM.
  5. Key Rotation and Management.  Due to the complexity and coordination required for this, we recommend some automation.  At a high level these are the steps:
    1. Create a new Key in the Managed HSM, incrementing the number in the Name.
    2. Update the CCL profile, and create a new PSE, following the same steps, with this new key.
    3. During a system downtime, update the user account in HANA, then distribute and swap in the new PSE on all application servers

Additional Security Recommendations

While the focus of this article is securing ABAP-to-HANA authentication, organizations should also review other pathways used to access SAP HANA. Reducing the risk associated with one credential provides limited security benefit if less secure authentication methods remain available. As with any security architecture, the overall security posture is ultimately constrained by its weakest link.

  1. Restrict direct username and password authentication wherever possible, retaining only tightly controlled break-glass accounts for emergency access.
  2. Integrate user authentication with a centralized identity provider and enforce Multi-Factor Authentication (MFA) for all interactive access.
  3. Secure all application and integration connections using either certificate-based authentication, with private keys protected by an HSM or secure key management system such as Azure Key Vault, or federated authentication through an identity provider.
  4. Review and remove unused technical users, certificates, service accounts, and integration endpoints on a regular basis.

In Conclusion

By leveraging Azure Key Vault Managed HSM, SAP customers can eliminate one of the most significant security concerns associated with traditional ABAP-to-HANA authentication: the use of portable credentials. Instead of relying on passwords or exportable private keys stored on the operating system, cryptographic operations are performed within a hardware security boundary, ensuring that authentication credentials cannot be copied and reused elsewhere.

While this approach introduces additional infrastructure and operational considerations, it provides a significantly stronger security posture for highly privileged SAP HANA connections. For organizations seeking to reduce credential theft risk and align with modern security principles, HSM-backed certificate authentication offers a practical and effective solution.

Additional Notes

  1. This solution is only available for Managed HSM.  AKV Standard, AKV Premium, and Cloud HSM are all out of scope with no plans for support.
  2. This solution is not covered by any additional Microsoft Production support SLAs beyond those provided by the underlying Azure services.  You can review the Azure SLAs here.
Updated Oct 21, 2026
Version 1.0
No CommentsBe the first to comment