Cryptography in Cloud and Digital Transformation

Introduction and Context

Digital transformation has moved information systems from centrally managed data centres to distributed environments that combine public cloud infrastructure, software as a service (SaaS), application programming interfaces (APIs), containers, mobile devices, Internet of Things (IoT) systems, and automated data pipelines. Cryptography remains the principal technical means of protecting confidentiality, integrity, authenticity, and accountability across this complex environment. However, encryption alone does not answer the most important operational question: who controls the keys?

In a traditional data centre, an organisation may own the servers, storage, network, security modules, and cryptographic keys. In a cloud environment, responsibility is divided among the customer, cloud service provider (CSP), software supplier, managed service provider, and sometimes a separate key-management or identity provider. Consequently, evaluating a cryptographic design requires more than selecting an algorithm. It requires analysis of data location, trust boundaries, administrative access, key ownership, service availability, recovery arrangements, legal authority, and the consequences of key loss or misuse.

This chapter examines encryption and key-ownership models for contemporary digital architectures. It focuses on practical foundations appropriate to cybersecurity professionals who must select, configure, monitor, and govern cryptographic controls.

Learning Objectives

By the end of this chapter, you should be able to:

1. Explain how cloud and digital-transformation architectures alter cryptographic trust boundaries.
2. Distinguish encryption in transit, encryption at rest, and application-level or end-to-end encryption.
3. Compare provider-managed keys, customer-managed keys, bring-your-own-key (BYOK), hold-your-own-key (HYOK), and external key-management models.
4. Evaluate cryptographic controls for SaaS, APIs, containers, mobile systems, IoT, and zero-trust architectures.
5. Apply the shared-responsibility model to key management and data protection.
6. Identify governance, availability, privacy, compliance, and incident-response implications of key ownership.

1. Cryptography Beyond the Perimeter

A cryptographic system normally involves plaintext, a cryptographic algorithm, a key, and ciphertext. Encryption transforms readable data into ciphertext; decryption uses an appropriate key to recover the plaintext. Modern systems should use established, peer-reviewed algorithms rather than proprietary encryption.

For symmetric encryption, the same secret key is used for encryption and decryption:

where P is plaintext, C is ciphertext, K is a secret key, and Enc_K is the encryption operation under key K. Decryption satisfies:

The equations describe the functional relationship, not a specific algorithm. In practice, authenticated encryption, such as AES-GCM or ChaCha20-Poly1305, should normally be preferred because it protects confidentiality and detects unauthorised modification. A system must never reuse a nonce with the same key where the selected authenticated-encryption mode prohibits such reuse.

Asymmetric cryptography uses a public key and a private key. Public-key mechanisms are useful for identity, digital signatures, and establishing shared secrets, but they are generally less efficient than symmetric encryption for bulk data. A common architecture therefore uses asymmetric cryptography to establish or protect a short-lived symmetric data-encryption key (DEK).

A digital signature provides authenticity and integrity, but it is not the same as encryption. A signature is generated with a private signing key and verified with the corresponding public key. Hash functions provide fixed-length digests used for integrity checking, indexing, password-protection schemes, and signature systems; a hash digest is not reversible encryption.

Encryption locations

Encryption can be applied at several layers:

Encryption in transit is essential for APIs, administrative consoles, service-to-service communication, mobile applications, and device connectivity. TLS protects a communication channel when certificate validation, protocol versions, cipher suites, and endpoint authentication are correctly configured. It does not protect a compromised endpoint or data after a receiving service decrypts it.

Encryption at rest protects persistent storage such as object storage, databases, snapshots, backups, container volumes, and mobile files. It reduces exposure from stolen media or unauthorised storage access, but it does not necessarily stop a cloud administrator, compromised workload, or authorised application from requesting plaintext.

Application-layer encryption provides stronger separation between the data owner and infrastructure provider. For example, a client application may encrypt sensitive fields before transmitting them to a SaaS platform. This can reduce provider visibility, but may disable server-side searching, analytics, malware scanning, data-loss prevention, and recovery functions unless specialised techniques are used.

2. The Key-Ownership Continuum

Key ownership is not a single binary condition. It includes possession, generation, storage, use, rotation, recovery, audit, and destruction. An organisation may legally own data while a provider technically controls the keys. Conversely, an organisation may operate a key-management service while a cloud application still receives plaintext during normal processing.

Provider-managed keys

With provider-managed keys, the CSP generates, stores, rotates, and uses keys on behalf of the customer. This model is usually simple, inexpensive, and highly available. It is appropriate for many ordinary workloads, especially where regulatory requirements do not demand exclusive customer control.

Its limitations include reduced control over key-generation procedures, provider personnel access, separation of duties, deletion timing, and the ability to demonstrate exclusive control. Provider-managed encryption also does not automatically provide application-level confidentiality.

Customer-managed keys

Customer-managed keys (CMKs) are administered by the customer through a cloud key-management service (KMS). The customer can usually define access policies, rotation schedules, logging, and administrative roles. The provider still hosts or operates part of the KMS and may perform cryptographic operations on the customer’s behalf.

A CMK can often be disabled to interrupt access to protected resources. This is powerful but dangerous: disabling a key can cause service outages, data unavailability, and failed backups or deployments. Key administration must therefore be separated from emergency decisions and governed by tested procedures.

Bring your own key

In a BYOK arrangement, the customer generates or imports key material into the provider’s KMS. BYOK can improve control over generation, provenance, and lifecycle management. It may support compliance requirements that require documented customer involvement in key creation.

BYOK does not necessarily mean that the customer retains exclusive control. Once imported, the provider may hold and use the key within its managed service. A BYOK assessment should ask:

• Can the customer export or destroy the key?
• Can the provider use the key without customer authorisation?
• Is key material held in hardware security modules (HSMs)?
• Who can restore, rotate, or disable it?
• What happens to encrypted data if the cloud account is suspended?
• Are logs independently available to the customer?

Hold your own key and external key management

In HYOK, keys remain in an infrastructure controlled by the customer, and the cloud service requests cryptographic operations from that infrastructure. External key management similarly places keys in a separate KMS or HSM environment. These arrangements can provide stronger separation from the CSP and may support strict sovereignty or contractual requirements.

They introduce additional dependencies. If a cloud service cannot reach the external key service, users may be unable to read or write data. Network failures, certificate expiry, incorrect firewall rules, HSM exhaustion, and disaster-recovery gaps can become business outages. Stronger control therefore comes with greater operational responsibility.

Envelope encryption

Envelope encryption separates data encryption from key-encryption operations. A randomly generated DEK encrypts the data. A key-encryption key (KEK), commonly held in a KMS or HSM, encrypts the DEK. The encrypted DEK is stored with the ciphertext, while the KEK remains protected by the KMS.

Here DEK is the data-encryption key and E is the encrypted form of that key. The data itself is encrypted separately as C = Enc_DEK(P). Envelope encryption improves scalability because large data objects are not repeatedly processed by the KMS. It also supports key rotation: a DEK may remain unchanged while its encrypted wrapper is replaced under a new KEK, subject to the service’s design and security policy.

3. Cloud Service Models and Shared Responsibility

The shared-responsibility model assigns different security tasks to the provider and customer. The exact boundary varies by service and contract.

The model is not a substitute for a service-specific responsibility matrix. A customer remains responsible for configuring encryption, granting permissions, protecting credentials, selecting retention periods, and verifying provider claims. “Encrypted by default” may mean that the provider encrypts storage, but it does not establish customer-exclusive control or protect against every privileged access path.

A sound evaluation examines the full data lifecycle: collection, transmission, processing, temporary files, caching, backups, replication, analytics, archival, deletion, and legal discovery. Encryption must be considered at each stage.

4. Cryptography in Contemporary Architectures

SaaS

SaaS customers should distinguish tenant isolation, provider storage encryption, customer-managed keys, and client-side encryption. A SaaS platform may encrypt each tenant’s storage while still processing plaintext in shared application infrastructure. Important questions concern administrative access, support personnel, subcontractors, backups, search indexes, logs, exports, and deletion verification.

Client-side or field-level encryption is appropriate for highly sensitive information, but it may prevent ordinary SaaS features. A practical design may classify data: routine business data can use provider or customer-managed storage keys, while regulated identifiers or strategic documents receive application-level protection.

APIs and microservices

APIs require confidentiality, endpoint authentication, authorisation, integrity, replay resistance, and careful secret management. TLS should be used for external and internal service communication. Mutual TLS (mTLS) can authenticate both client and server in service-to-service environments, although certificate issuance and rotation must be automated.

API keys are identifiers or shared secrets, not a complete authorisation architecture. They should be scoped, short-lived where possible, stored in a secrets-management service, monitored, and revocable. OAuth 2.0 access tokens can delegate limited authority, while signed tokens require careful validation of issuer, audience, algorithm, expiry, and key-rotation metadata. Sensitive payloads may require message-level signatures or encryption when intermediaries terminate TLS.

Containers and orchestration

Container images should be signed and verified to protect supply-chain integrity. Secrets must not be embedded in images, source code, container layers, or public environment variables. Orchestrators should use encrypted secret stores, workload identities, network policies, and short-lived credentials.

Encryption of a container volume protects persistent data, but it does not automatically protect data from a process running with access to the mounted volume. The security boundary is the workload identity and its authorisation policy, not merely the container abstraction.

Mobile applications

Mobile devices are untrusted execution environments. Applications should use platform-provided secure storage, hardware-backed keystores where available, certificate validation, authenticated encryption, and remote revocation. Private keys should not be hard-coded into an application because reverse engineering can expose them. Device encryption protects lost hardware but does not prevent a malicious or compromised application from accessing data while the device is unlocked.

A mobile design should minimise local data, use short-lived tokens, support remote logout, and assume that application binaries and client-side logic can be inspected. High-value decisions should be enforced by trusted backend services rather than solely by mobile code.

IoT

IoT devices may have limited processing power, long deployment lifetimes, poor physical protection, and irregular patching. Each device should ideally possess a unique cryptographic identity established during secure provisioning. Mutual authentication, signed firmware, secure boot, protected key storage, and an update mechanism are more valuable than a shared factory password.

The operator must plan for certificate expiry, device replacement, manufacturing compromise, ownership transfer, and offline operation. A fleet-wide shared key creates a catastrophic single point of compromise and makes attribution difficult.

Zero-trust architectures

Zero trust does not mean that encryption replaces identity or policy. It means that access is continuously evaluated rather than granted solely because a device or user is inside a network perimeter. Cryptography supports zero trust through strong identity credentials, device certificates, mTLS, signed assertions, protected tokens, and integrity-protected policy decisions.

A zero-trust system should apply least privilege, authenticate workloads and users, segment communication, record security-relevant events, and re-evaluate access based on context. Key ownership must align with administrative independence: an organisation should not place all identity-signing, encryption, and recovery authority in one uncontrolled domain.

5. A Practical Evaluation Framework

A cryptographic architecture can be evaluated through six questions.

1. What must be protected? Classify data by confidentiality, integrity, availability, privacy, and business impact.
2. Who must be unable to read it? Identify cloud operators, application administrators, contractors, other tenants, compromised workloads, and legal or jurisdictional actors.
3. Where does plaintext exist? Map endpoints, memory, databases, queues, logs, backups, analytics platforms, and support tools.
4. Who controls the keys? Document generation, custody, usage approval, rotation, recovery, destruction, and audit.
5. What happens during failure? Test key-service outage, expired certificates, accidental deletion, account suspension, region loss, and ransomware response.
6. Can the claims be evidenced? Require audit logs, independent assurance reports, contractual commitments, penetration-test results, and configuration evidence.

A useful decision principle is proportionality. Exclusive external key control may be justified for highly regulated or strategically sensitive data, but it can be excessive for low-risk content if it creates unacceptable availability and operational complexity. The correct design balances confidentiality against availability, usability, recoverability, cost, performance, and auditability.

6. Key Lifecycle and Governance

Key management is a lifecycle, not a one-time configuration. The lifecycle includes generation, registration, distribution, activation, use, rotation, suspension, backup, recovery, archival, compromise response, and destruction. Separation of duties should prevent one person from generating, approving, using, and deleting critical keys without oversight.

Keys should be generated using approved random-number sources and stored in protected KMS or HSM services. Access should be based on least privilege and workload identity rather than broad administrator permissions. Rotation should be risk-based and should account for algorithm limits, compromise indicators, contractual requirements, and operational impact. Rotation does not remove old ciphertext unless data is re-encrypted or the old key is securely destroyed after all legitimate dependencies end.

Backups of keys require special care. A backup that is accessible to the same administrators and environment as the primary key may not provide meaningful resilience. Conversely, destroying every copy may make data permanently unrecoverable. Recovery procedures should be documented, dual-controlled, tested, and linked to business-continuity plans.

Key destruction is a security and governance event. It may render data inaccessible, but it does not necessarily prove that every plaintext copy, cache, export, or backup has been deleted. Cryptographic erasure is strongest when all relevant copies are encrypted with uniquely controlled keys and retention dependencies are understood.

7. Applied Case: Illustrative Health-Services Migration

Background

A fictional regional health provider, NorthRiver Health, moves appointment, billing, and clinical-document services to a public cloud. It uses a SaaS collaboration platform, a cloud database, mobile clinician applications, and IoT monitoring devices.

Problem

The organisation initially enables provider-managed encryption everywhere. An assessment identifies three concerns: clinical documents are replicated across several regions; administrators can access application data during support operations; and the IoT fleet uses a shared device credential. The organisation must improve control without making clinical services unavailable during a KMS outage.

Analysis

Clinical documents require stronger confidentiality than appointment reminders. The SaaS platform cannot perform full-text search on client-side encrypted documents, while clinicians need search functionality. The cloud database supports customer-managed envelope encryption and detailed key-use logs. Mobile devices may be lost, and IoT devices can be physically accessed.

Approach

NorthRiver adopts a tiered model:

• Provider-managed encryption for low-sensitivity public information.
• Customer-managed keys for databases, backups, and object storage.
• Field-level application encryption for selected clinical identifiers, with carefully designed tokenisation for required searches.
• mTLS and workload identities for internal services.
• Hardware-backed mobile keystores, short-lived tokens, and minimal local storage.
• Unique device certificates, signed firmware, and device revocation for IoT.
• A separate recovery key held under dual control and tested in a second region.

The organisation retains an external approval service for particularly sensitive key-use operations, but it does not require every transaction to depend on an external network path. Availability requirements are documented so that emergency access is possible but audited.

Outcome

The design improves separation from the provider and creates evidence of key use, while preserving ordinary search and clinical workflows through selective encryption and tokenisation. The organisation also discovers that key disabling is not an acceptable first response to every suspected incident because it could prevent emergency care. Instead, incident playbooks define staged containment, service isolation, key suspension criteria, and emergency authorisation.

Learning points

The case demonstrates that no single key model is universally best. Data classification, functionality, availability, provider capability, and recovery requirements must be evaluated together. It also shows that cryptography cannot correct weak identity management, shared credentials, insecure devices, or poorly governed support access.

8. Limitations, Ethics, and Regulation

Encryption can protect stored and transmitted information, but it cannot guarantee confidentiality when endpoints are compromised or authorised users misuse data. Metadata such as timing, account relationships, location, volume, and traffic patterns may remain visible. Strong encryption can also create lawful-access disputes, complicate safety investigations, and make recovery impossible if keys are lost.

Organisations should avoid deceptive claims such as “fully secure,” “zero access,” or “end-to-end encrypted” unless the technical boundary is precisely defined. Privacy obligations require data minimisation, purpose limitation, retention control, access accountability, and appropriate technical safeguards. Key custody may affect jurisdiction, cross-border transfer, discovery, and regulatory evidence.

Artificial intelligence systems intensify these concerns because training data, prompts, embeddings, logs, and model outputs may be copied across services. Sensitive data should be classified before use in AI platforms. Encryption protects stored prompts and transport channels, but it does not prevent a model operator or authorised inference service from processing plaintext. Access controls, retention settings, tenant isolation, and contractual restrictions remain necessary.

9. Best Practices

1. Classify data and map every location where plaintext or ciphertext exists.
2. Use authenticated encryption and current, widely reviewed protocols.
3. Prefer workload identities and short-lived credentials over shared secrets.
4. Treat BYOK as a control improvement, not automatic proof of exclusive ownership.
5. Document the complete key lifecycle and test recovery before production reliance.
6. Separate key administrators, security operators, application owners, and auditors.
7. Use unique device or workload credentials; never rely on fleet-wide default keys.
8. Monitor key use, unusual decryption volume, policy changes, and failed authentication.
9. Design for certificate, KMS, network, region, and account failures.
10. Verify provider claims through contracts, technical documentation, audit evidence, and independent testing.
11. Reassess controls when data, providers, regions, applications, or regulations change.
12. Make emergency access exceptional, time-limited, justified, and auditable.

Chapter Summary

Cloud and digital transformation distribute data and administrative authority across many trust boundaries. Encryption should therefore be evaluated by location, purpose, endpoint, identity, and key custody rather than treated as a single checkbox. Transport encryption protects communications; storage encryption protects persistent media; application and end-to-end encryption can reduce provider visibility but may limit functionality.

Provider-managed keys offer simplicity, while customer-managed, BYOK, HYOK, and external KMS models provide progressively greater customer participation or separation, accompanied by increased responsibility and availability risk. Envelope encryption enables scalable protection by using DEKs for data and KEKs for key protection. Shared responsibility requires customers to verify configuration, access, lifecycle, logging, recovery, and provider claims.

SaaS, APIs, containers, mobile devices, IoT, and zero-trust architectures require identity-aware cryptography, secure provisioning, authenticated communication, protected secrets, and tested recovery. Effective protection combines cryptographic technology with governance, least privilege, monitoring, data minimisation, and realistic incident-response procedures.

Key Terms

Cryptography: The discipline of protecting information using mathematical techniques.

Plaintext: Readable or otherwise intelligible original data.

Ciphertext: Data transformed by encryption so that it is not intelligible without appropriate decryption.

Symmetric encryption: Encryption using the same secret key, or related secret material, for encryption and decryption.

Asymmetric cryptography: Cryptography using mathematically related public and private keys.

Authenticated encryption: Encryption that provides confidentiality and detects unauthorised modification.

Digital signature: A private-key-generated value used to provide integrity, authenticity, and non-repudiation evidence.

Key-management service (KMS): A service that generates, stores, uses, and manages cryptographic keys.

Hardware security module (HSM): Tamper-resistant hardware designed to protect cryptographic keys and operations.

Data-encryption key (DEK): A key used to encrypt application or storage data.

Key-encryption key (KEK): A key used to encrypt or wrap another key.

Envelope encryption: A design in which a DEK encrypts data and a KEK protects the DEK.

Provider-managed key: A key generated and operated primarily by a cloud provider.

Customer-managed key: A key administered by the customer through a provider or external KMS.

BYOK: Bring your own key; importing or supplying customer-generated key material to a provider.

HYOK: Hold your own key; retaining key control outside the cloud service provider.

Shared responsibility: A model dividing security obligations between provider and customer.

Mutual TLS: TLS in which both communicating parties authenticate using certificates.

Zero trust: A security approach that continuously verifies identity, context, and authorisation rather than trusting network location.

Cryptographic erasure: Making encrypted data inaccessible by securely destroying the keys required to decrypt it.

Review Questions

Short Answer Questions

1. What is the difference between encryption at rest and application-layer encryption?
2. Why does BYOK not necessarily provide exclusive customer control?
3. Define envelope encryption and identify its two principal key types.
4. Why are shared IoT fleet keys a significant security weakness?
5. What does the shared-responsibility model require a cloud customer to do?

Long Answer Questions

1. Compare provider-managed keys, customer-managed keys, BYOK, and HYOK in terms of control, complexity, availability, and risk.
2. Explain how cryptographic requirements differ among SaaS, APIs, containers, mobile applications, and IoT systems.
3. Discuss how zero-trust architecture uses cryptography without treating encryption as a replacement for identity and authorisation.
4. Analyse the advantages and limitations of client-side encryption for a collaborative SaaS platform.
5. Explain the key lifecycle and describe why recovery and destruction require formal governance.

Analytical / Application Questions

1. A company wants to disable its cloud encryption key immediately after detecting suspicious administrator activity. What availability and investigative risks should be assessed, and what staged alternatives could be used?
2. Design a key-ownership model for a healthcare SaaS system that requires provider-side search but must protect selected clinical identifiers from routine provider access.
3. An IoT manufacturer proposes one symmetric key for 100,000 devices to reduce cost. Evaluate the proposal and recommend a more resilient provisioning, authentication, and revocation design.

Multiple Choice Questions with Answers

Question 1

Which statement best describes envelope encryption?

A. A single public key encrypts every data object directly.

B. A data-encryption key encrypts data and a key-encryption key protects the data-encryption key.

C. Plaintext is stored openly while only metadata is encrypted.

D. A hash function is used to recover plaintext from a digest.

Correct Answer: B. A data-encryption key encrypts data and a key-encryption key protects the data-encryption key.

Question 2

What is the principal limitation of encryption in transit?

A. It cannot protect data while it travels between systems.

B. It prevents all endpoint authentication.

C. It does not automatically protect data after it is decrypted at an endpoint.

D. It can be used only for public websites.

Correct Answer: C. It does not automatically protect data after it is decrypted at an endpoint.

Question 3

Which key model normally gives a customer the greatest separation from a cloud provider?

A. Provider-managed keys

B. Default storage encryption

C. Customer-managed keys hosted entirely by the same provider

D. Hold-your-own-key with an externally controlled key service

Correct Answer: D. Hold-your-own-key with an externally controlled key service

Question 4

Why should API secrets generally be short-lived and scoped?

A. To increase the amount of data visible to every service

B. To reduce the impact of compromise and limit authorised actions

C. To eliminate the need for TLS

D. To make secrets permanently unrevocable

Correct Answer: B. To reduce the impact of compromise and limit authorised actions

Question 5

Which practice is most appropriate for container security?

A. Embed production secrets in the container image.

B. Use one administrator credential for every workload.

C. Store secrets in a protected secret-management service and use workload identities.

D. Disable image verification to improve deployment speed.

Correct Answer: C. Store secrets in a protected secret-management service and use workload identities.

Question 6

What is a major risk of using one shared cryptographic key across an entire IoT fleet?

A. Compromise of one device may expose or affect the entire fleet.

B. It guarantees precise device-level attribution.

C. It prevents all firmware updates.

D. It makes certificate rotation unnecessary and risk-free.

Correct Answer: A. Compromise of one device may expose or affect the entire fleet.

Question 7

Which statement about BYOK is correct?

A. It always means the provider can never use the key.

B. It may allow customer-controlled generation while the provider still hosts and operates the imported key.

C. It eliminates the need for key recovery.

D. It is identical to client-side end-to-end encryption in every respect.

Correct Answer: B. It may allow customer-controlled generation while the provider still hosts and operates the imported key.

Question 8

In a zero-trust architecture, cryptography primarily supports which function?

A. Trusting every device inside the corporate network

B. Replacing all authorisation decisions with encryption

C. Identity, authenticated communication, protected tokens, and integrity of decisions

D. Removing the need for monitoring and logging

Correct Answer: C. Identity, authenticated communication, protected tokens, and integrity of decisions

Question 9

Which action is an example of cryptographic erasure?

A. Deleting a user interface shortcut

B. Destroying the keys required to decrypt data, after confirming all retention obligations

C. Changing a database table name

D. Compressing plaintext backups

Correct Answer: B. Destroying the keys required to decrypt data, after confirming all retention obligations

Question 10

A customer-managed key is disabled without a recovery plan. What is the most immediate likely consequence?

A. Encrypted resources may become unavailable to legitimate applications.

B. All ciphertext automatically becomes plaintext.

C. The provider loses all network connectivity.

D. Digital signatures become stronger.

Correct Answer: A. Encrypted resources may become unavailable to legitimate applications.