Confidential Computing
As of 2026-08-16
Confidential computing is the SAP analytics topic where the honest answer is more valuable than the optimistic one: SAP HANA on confidential VMs sits at TRL 6-7 (piloted, not certified), and BTP-native confidential compute is still TRL 3-4 -- a gap most vendors gloss over and clients rarely know to ask about. The decision that matters in week one is hardware, not software: Intel SGX's 128-512 MB enclave ceiling rules it out for in-memory analytics, while AMD SEV-SNP's VM-level model is the only realistic path to run HANA unmodified. DORA (binding since January 2025) and the EU Data Act (September 2025) are turning this from an R&D curiosity into a procurement requirement for financial-services and pharma consortium analytics. Consultants who can separate what SAP ships today from what SAP is still researching -- and design the multi-party attestation flow either way -- sit in a small, EMEA-concentrated specialist pool commanding a premium over general SAP analytics day rates.
What you will learn
- Explain the specific threat vector that hardware TEEs (Intel SGX, AMD SEV-SNP) address -- data-in-use exposure -- and distinguish it from the protections provided by standard encryption at rest and in transit in SAP cloud architectures.
- Assess the architectural fit of SGX versus SEV-SNP for a given SAP analytics workload, applying the SGX EPC memory constraint, the SEV-SNP VM-level isolation model, and remote attestation requirements to select the appropriate TEE technology.
- Design a multi-party analytics architecture using confidential compute for a regulated industry use case (financial services consortium or pharmaceutical cross-trial), specifying the attestation flow, key management integration with SAP Data Custodian, and the governance structure for the enclave.
- Accurately represent the current TRL (Technology Readiness Level) of confidential computing in SAP BTP and SAP HANA to a client stakeholder, mapping DORA, EU Data Act, and Gaia-X regulatory requirements to the appropriate SAP engagement path.
The Problem Confidential Computing Actually Solves
Every cloud analytics architecture makes a security assumption that most architects never examine explicitly: data that is encrypted at rest (on disk) and in transit (over the network) is decrypted in memory when it is being processed. That means the cloud provider's hypervisor, operating system, and privileged administrative accounts have -- in principle -- visibility into the plaintext data while computation is occurring. For most enterprise analytics workloads, this is an acceptable risk posture. For specific classes of SAP workloads -- multi-party analytics involving data that no single party is willing to expose to the others, regulated financial or healthcare data under strict sovereignty requirements, or high-sensitivity merger and acquisition analytics -- it is not.
Confidential computing addresses precisely this gap by introducing hardware-level isolation that prevents even privileged system software from reading a process's memory contents. The key concept is the Trusted Execution Environment (TEE): a hardware-enforced enclave inside the CPU where code and data can run with cryptographic guarantees that the contents are inaccessible to the host operating system, the hypervisor, and any other process, including the cloud provider's infrastructure software.
Prerequisites
- Intermediate hands-on experience on SAP analytics projects
- Review core concepts first: C087, C083, C047
Outcomes
- Understand the core concepts behind confidential computing
- Apply Confidential in a typical SAP analytics engagement
- Explain the core architecture and decision points for Confidential Computing
- Apply a repeatable implementation pattern in a 15-minute lab format
Full module available to members. The full module adds: the decision framework · the end-to-end scenario walkthrough · the KPI scorecard · the anti-patterns · the code blocks · the knowledge check · the diagrams.