Cryptographic Operations and Decision Making

Introduction

Cryptography is often introduced as a technical discipline concerned with encryption, hashing, keys, and digital signatures. In professional security practice, however, cryptography is also a management problem. An organisation must know where cryptography is used, what information it protects, whether controls are proportionate to risk, how suppliers implement them, and how cryptographic services will be maintained throughout their life cycle.

Poor cryptographic decisions rarely fail because an algorithm is mathematically broken. They more commonly fail because a certificate expires, a private key is copied, an obsolete protocol remains enabled, a supplier cannot explain its key-management process, or an organisation cannot identify systems affected by a newly discovered vulnerability. Effective cryptographic governance therefore connects technical controls with risk assessment, procurement, operations, incident response, compliance, cost, and business continuity.

This chapter presents a practical decision-making framework for diploma-level cybersecurity professionals. It focuses on cryptographic inventories, risk assessment, control selection, supplier evaluation, certificate monitoring, incident response, metrics, cost-risk comparison, and lifecycle planning.

Learning Objectives

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

1. Explain why cryptographic governance is a strategic security activity.
2. Construct and maintain a cryptographic inventory.
3. Assess cryptographic risk using likelihood, impact, and exposure information.
4. Select controls for encryption, hashing, signatures, key management, and certificate operations.
5. Evaluate vendors and cloud providers against cryptographic requirements.
6. Design certificate-monitoring and cryptographic incident-response processes.
7. Interpret operational metrics and distinguish useful measures from misleading ones.
8. Compare cryptographic investments using cost, risk reduction, and business consequences.
9. Develop a practical cryptographic lifecycle and migration plan.

1. Cryptography as an Organisational Capability

A cryptographic capability consists of more than algorithms. It includes:

• cryptographic assets, such as keys, certificates, hardware security modules, trust stores, and cryptographic libraries;
• protected information and business services;
• policies, standards, procedures, and approval authorities;
• people and roles, including certificate owners, key custodians, system administrators, and incident responders;
• technology suppliers and external trust providers; and
• monitoring, testing, recovery, and retirement processes.

The security objectives remain confidentiality, integrity, authenticity, and non-repudiation where applicable. Different cryptographic mechanisms support these objectives differently. Encryption primarily supports confidentiality; message authentication codes and digital signatures support integrity and authenticity; hashing supports integrity checks and password-verification designs when used with suitable password-hashing methods. No mechanism provides every security property automatically.

A useful managerial principle is that cryptography should be governed according to information value and operational dependency. A public web page does not require the same key-management controls as a payment database, but both may depend on certificates. Similarly, an algorithm may be mathematically strong while its implementation, configuration, or key storage is weak.

2. The Cryptographic Inventory

2.1 Purpose and scope

A cryptographic inventory is a controlled record of where cryptography is used, what it protects, who owns it, and how it can be changed. It should cover production, development, test, backup, disaster-recovery, mobile, cloud, network, endpoint, application, database, and embedded environments.

The inventory should include both visible and hidden uses of cryptography. Visible uses include TLS certificates, VPN tunnels, encrypted databases, and public-key infrastructure. Hidden uses include application libraries, hard-coded keys, backup encryption, tokenisation services, operating-system disk encryption, software-signing keys, and third-party APIs.

2.2 Recommended inventory fields

The inventory should be authoritative enough to support an emergency question such as: “Which systems use this compromised certificate or vulnerable cryptographic library?” A spreadsheet may be suitable for a small organisation, but larger environments generally require discovery tools, configuration-management databases, certificate-management platforms, and documented ownership.

2.3 Inventory methods

Inventory development normally combines several methods:

1. Document review: examine architecture diagrams, procurement records, policies, data-flow diagrams, and supplier contracts.
2. Configuration discovery: inspect servers, endpoints, network devices, application settings, databases, and cloud services.
3. Certificate discovery: scan internal and external domains, load balancers, reverse proxies, service meshes, and application repositories.
4. Code and pipeline review: search for cryptographic libraries, hard-coded secrets, weak algorithms, and insecure randomness.
5. Interviews and workshops: identify undocumented business processes and legacy dependencies.
6. Validation: ask owners to confirm purpose, exposure, criticality, and recovery arrangements.

Discovery alone is not governance. Every record should have an owner, a review date, and a process for correction. Inventory accuracy can be measured by sampling records against actual configurations, but the result should be interpreted carefully: a high percentage of populated records does not necessarily mean the inventory is complete.

3. Cryptographic Risk Assessment

3.1 Risk concepts

Cryptographic risk arises when a threat can exploit a weakness and produce harm. Examples include interception of sensitive data, fraudulent signatures, unauthorised decryption, service outage caused by certificate expiry, or inability to access encrypted records after key loss.

A basic qualitative model is:

Likelihood expresses the chance or frequency of an adverse event over a defined period. Impact expresses the consequences if it occurs. Both must be defined consistently. A five-point likelihood scale and a five-point impact scale may be useful, but the numbers are ranking values rather than precise probabilities unless explicitly calibrated.

Risk assessment should consider:

• data sensitivity and legal obligations;
• exposure to the internet, partners, insiders, or hostile networks;
• algorithm and protocol strength;
• key length, randomness, storage, rotation, and access control;
• implementation quality and patch status;
• dependency on certificates, trust anchors, or external services;
• recovery and revocation capability;
• duration of exposure;
• threat capability and motivation; and
• business continuity consequences.

3.2 Inherent and residual risk

Inherent risk is the risk before considering controls. Residual risk is the risk remaining after controls are applied. A control may reduce likelihood, impact, or both. For example, a hardware security module can reduce the likelihood of private-key extraction, while tested key recovery can reduce the impact of key loss.

Risk ratings should not be treated as objective facts. A “high” rating is meaningful only when the organisation has defined what high means and applied the definition consistently. Management should also record risk acceptance, transfer, reduction, or avoidance decisions, including the responsible authority and review date.

3.3 Worked risk example

An organisation identifies an internet-facing service using an expired or weakly managed certificate. Before remediation, the team rates likelihood as 4 on a five-point scale and impact as 5. Using a simple ranking model:

If automated renewal, ownership assignment, and alerting reduce the likelihood rating to 1 while impact remains 5:

The score falls from 20 to 5, but this does not prove that risk has been reduced by exactly 75 percent. Ordinal ratings do not normally support such arithmetic interpretation. The example demonstrates prioritisation, not a measured probability reduction.

4. Selecting Cryptographic Controls

Control selection should begin with the business requirement rather than a favourite algorithm. The following questions are useful:

1. What information or transaction requires protection?
2. Which security properties are required?
3. Who are the trusted and untrusted parties?
4. How long must protection remain effective?
5. What availability and recovery requirements apply?
6. What legal, contractual, interoperability, or architectural constraints exist?
7. Who will operate, monitor, rotate, revoke, and retire the control?

4.1 Control categories

Controls must be configured securely. Encryption without authenticated integrity protection can permit undetected modification. Certificate-based authentication without private-key protection can permit impersonation. Key rotation without dependency mapping can cause outages. Therefore, controls should be selected as operational systems, not isolated technical features.

4.2 Control assurance

Assurance activities include configuration review, code review, penetration testing, vulnerability scanning, key-ceremony observation, access-log analysis, disaster-recovery exercises, and supplier evidence review. Security claims should be matched to evidence. A vendor statement that “data is encrypted” is incomplete unless it identifies data locations, algorithms, key ownership, access paths, logging, and recovery arrangements.

5. Evaluating Vendors and Cloud Providers

Third-party cryptographic risk is shared risk. An organisation may outsource infrastructure but normally retains responsibility for deciding what data may be processed, what assurance is required, and how incidents will be handled.

5.1 Vendor evaluation domains

A vendor assessment should address:

• algorithms, protocols, modes, and cryptographic libraries;
• key generation, storage, rotation, backup, destruction, and access;
• hardware-backed protection and administrator separation;
• certificate issuance, renewal, revocation, and monitoring;
• tenant isolation and provider access;
• logging, alerting, and retention;
• vulnerability management and secure development;
• independent audits and relevant certifications;
• incident notification timeframes and cooperation duties;
• portability, exit, and data-decryption arrangements; and
• continuity if the provider fails or the contract ends.

5.2 Questions that expose weak assurance

A procurement questionnaire should avoid vague questions such as “Is customer data secure?” More useful questions include:

• Can the customer control or supply its own keys?
• Can provider personnel access plaintext or key material?
• Are keys separated by tenant, environment, and purpose?
• What happens when an employee with privileged access leaves?
• How are emergency key revocation and certificate replacement performed?
• Can the provider demonstrate restoration of encrypted backups?
• Which cryptographic libraries and protocols are used, and how are they updated?
• What evidence is supplied after a suspected key compromise?

Contracts should define security responsibilities, notification, evidence access, audit rights, service levels, breach cooperation, deletion, and exit support. A technically excellent supplier can still be unsuitable if its operating model does not meet the organisation’s recovery or regulatory needs.

6. Certificate and Key Operations

Certificates have finite validity periods and depend on a chain of trust. Certificate management therefore requires ownership, discovery, renewal, deployment, validation, revocation, and retirement. Expiry is not the only problem: certificates may contain incorrect names, use unsuitable algorithms, be issued by an unapproved authority, or have private keys exposed.

A mature monitoring process should:

1. discover certificates in internal and external environments;
2. record subject names, alternative names, issuer, validity, algorithm, and owner;
3. alert at multiple intervals before expiry;
4. distinguish warning, escalation, and emergency thresholds;
5. test the renewal process in advance;
6. verify deployment across all dependent systems;
7. confirm the complete trust chain; and
8. remove retired certificates and keys where appropriate.

Alerting should be based on operational risk, not merely calendar dates. A certificate expiring in 20 days may be critical for a global service with a lengthy change process but low risk for a test system that is already scheduled for removal.

Key management includes generation, distribution, use, rotation, archival, recovery, revocation, destruction, and evidence. Key access should follow least privilege and separation of duties. Private keys should not be stored in source code, shared chat messages, unmanaged files, or general-purpose databases. Where justified by risk, hardware security modules can provide protected key operations and administrative separation, but they also introduce cost, specialist skills, availability dependencies, and recovery requirements.

7. Cryptographic Incident Response

A cryptographic incident may involve a compromised private key, stolen key material, a vulnerable library, certificate mis-issuance, algorithm failure, loss of key access, or unauthorised decryption. Incident response should be prepared before the event because emergency decisions often have broad operational consequences.

7.1 Preparation

Preparation includes current inventories, contact lists, authority to revoke or replace keys, tested backups, emergency change procedures, vendor contacts, logging, and rehearsals. Organisations should identify which events require legal, regulatory, customer, or partner notification.

7.2 Identification and analysis

The team should establish what was affected, when exposure began, whether private keys were accessed, which systems trust the key, and whether confidentiality or authenticity can still be relied upon. Logs, endpoint evidence, HSM records, certificate-transparency information, code repositories, and supplier reports may be relevant.

7.3 Containment and eradication

Containment may include disabling a certificate, blocking a compromised account, isolating a host, suspending a signing service, or restricting key use. Eradication requires removal of malicious access, patching vulnerable components, replacing keys, and rebuilding affected trust relationships. Revocation alone is insufficient if clients do not check revocation status or if the compromised key remains active elsewhere.

7.4 Recovery and lessons learned

Recovery includes deployment of replacement certificates or keys, validation of dependent services, restoration testing, customer communication, and enhanced monitoring. The post-incident review should identify why discovery, ownership, access control, alerting, or recovery failed. The objective is not only to replace a key but to reduce recurrence.

8. Metrics for Cryptographic Governance

Metrics should support decisions. Useful indicators include:

• percentage of cryptographic assets with an accountable owner;
• percentage inventoried and validated within the review period;
• number of certificates expiring within defined thresholds;
• percentage of certificates renewed before the emergency window;
• number of unsupported algorithms, protocols, or libraries;
• mean time to revoke and replace a compromised certificate;
• percentage of key restorations successfully tested;
• number of secrets detected in source repositories;
• percentage of critical suppliers with current cryptographic assurance evidence; and
• number and age of approved exceptions.

A basic coverage rate can be expressed as:

The measure is meaningful only if the denominator is credible. If the estimated total is too low, coverage will be overstated. Metrics should therefore include confidence, data source, scope, reporting period, and limitations.

Operational metrics should be balanced with outcome measures. Counting the number of keys rotated may encourage unnecessary rotation, while measuring successful recovery tests and reduction of unauthorised access is more informative. Metrics should not reward teams for hiding exceptions or classifying assets as low criticality without evidence.

9. Cost–Risk Decision Making

Cryptographic investment decisions involve direct and indirect costs. Direct costs include licences, hardware, cloud services, implementation, training, testing, and support. Indirect costs include downtime during migration, application redesign, performance effects, supplier dependence, and user disruption.

A simple decision comparison may use expected annual loss:

Probability must be expressed as a value between 0 and 1, and impact must use a defined monetary basis. For example, if an organisation estimates a 0.08 annual probability of a loss costing $500,000:

If a control costs $25,000 per year and is expected to reduce the probability to 0.02, the remaining expected loss is:

The estimated annual benefit is $30,000 before considering implementation and other effects. A simple net benefit is therefore:

This is not a guarantee of financial return. Estimates may be uncertain, impacts may be non-financial, and controls may satisfy legal or ethical duties even when their monetary case is weak. Sensitivity analysis should test how the decision changes under different probability, impact, and cost assumptions.

10. Cryptographic Lifecycle Planning

Cryptographic technologies should be managed through a lifecycle:

1. Requirement: define the information, security properties, retention period, interoperability, and recovery needs.
2. Design: select protocols, algorithms, key architecture, trust model, ownership, and monitoring.
3. Approval: document risk analysis, exceptions, supplier responsibilities, and implementation authority.
4. Deployment: configure, test, document, and register assets in the inventory.
5. Operation: monitor use, access, performance, expiry, vulnerabilities, and compliance.
6. Rotation or migration: replace keys, certificates, libraries, algorithms, or protocols before they become unacceptable.
7. Retirement: revoke, destroy, archive, or preserve material according to business and legal requirements.
8. Review: capture lessons, update standards, and reassess future threats.

Migration planning is especially important because cryptographic change can affect applications, devices, suppliers, archived data, and embedded systems. Organisations should maintain an approved cryptographic standard that identifies permitted, restricted, and prohibited mechanisms. Exceptions should have a business owner, compensating controls, expiry date, and migration plan.

Post-quantum planning

Large-scale quantum computers could threaten widely used public-key algorithms based on integer factorisation or discrete logarithms. The exact timing and capability remain uncertain, but long-lived confidential information may face “harvest now, decrypt later” risks. Sensible preparation includes inventorying public-key uses, identifying long-lived data, monitoring standards developments, requiring vendor roadmaps, and designing systems for algorithm agility. This does not mean replacing every system immediately; it means avoiding architectures that cannot support controlled migration.

11. Applied Case: Northbridge Health Services

Background

Northbridge Health Services is an illustrative regional healthcare provider with hospitals, clinics, a patient portal, laboratory systems, and cloud-hosted backups. An internal review discovers that certificates are recorded in separate spreadsheets, several applications use different encryption libraries, and one backup platform is managed by a third party.

Problem

A portal certificate expires unexpectedly, causing a six-hour service interruption. The organisation also cannot quickly determine whether the same private key was deployed on a disaster-recovery server. Management therefore requests a cryptographic improvement programme.

Analysis

The review identifies four major risks:

• incomplete inventory and unclear ownership;
• certificate expiry and deployment inconsistency;
• insufficient evidence about third-party key access; and
• untested recovery for encrypted backups.

The patient portal receives the highest priority because it is externally exposed and supports clinical communication. Backup encryption receives high priority because loss of keys could make records unavailable. Low-risk laboratory test systems are scheduled for a later migration, but their exception records include an expiry date.

Approach and solution

Northbridge creates a central inventory linked to service owners and configuration records. Automated discovery scans certificates and compares deployed certificates with approved records. The organisation establishes a certificate authority policy, multiple expiry alerts, emergency replacement authority, and a documented trust-chain validation step.

For key management, production signing and high-value encryption keys are moved to a managed, hardware-backed service. Access is separated between application operators and key administrators. Backup restoration is tested quarterly, with results reported to management. The cloud supplier must provide information on key access, logging, incident notification, deletion, and exit procedures.

A cryptographic standard classifies mechanisms as approved, restricted, or prohibited. Exceptions require risk acceptance and a migration date. The incident-response plan includes key compromise, certificate mis-issuance, and loss of decryption capability.

Outcome

The organisation reduces unmanaged certificates, establishes accountable owners, and completes restoration tests. Management receives a dashboard showing inventory coverage, certificates approaching expiry, unsupported mechanisms, and open exceptions. The programme does not eliminate all risk, but it makes risk visible, assignable, and actionable.

Learning points

1. A cryptographic inventory is an operational dependency map, not merely a list of algorithms.
2. Ownership and recovery are as important as technical strength.
3. Supplier assurance must be supported by contractual rights and evidence.
4. Metrics should reveal exposure and resilience rather than reward activity alone.
5. Migration should be planned before a crisis forces rushed replacement.

12. Governance, Ethics, and Professional Responsibility

Cryptographic decisions affect privacy, access to services, evidence, and public trust. Excessive retention of decryption keys may facilitate unnecessary surveillance; insufficient recovery capability may deny legitimate access to medical, financial, or safety-critical records. Professionals must therefore apply proportionality, purpose limitation, least privilege, and separation of duties.

Legal and regulatory requirements vary by jurisdiction, but common obligations include protection of personal data, secure processing, breach notification, records retention, sector-specific controls, and evidence preservation. Encryption does not automatically satisfy every requirement, and compliance does not prove that a system is secure.

Professionals should document assumptions, communicate uncertainty, avoid overstating vendor claims, and escalate unacceptable risk. Where lawful access, monitoring, or key escrow is considered, the organisation should evaluate necessity, safeguards, abuse potential, transparency, and independent oversight.

Challenges and Limitations

Cryptographic governance faces persistent difficulties:

• legacy systems may not support modern algorithms or automated renewal;
• inventories become inaccurate when ownership and change management are weak;
• cloud abstraction can obscure key locations and administrative access;
• risk estimates often rely on uncertain historical data;
• rotation can create outages when dependencies are unknown;
• strong controls may increase cost, latency, or operational complexity; and
• algorithm migration can affect devices with long replacement cycles.

These limitations do not justify inaction. They require prioritisation, compensating controls, documented exceptions, staged migration, and continuous review.

Best-Practice Checklist

A practical cryptographic governance programme should:

• maintain an owned and regularly validated inventory;
• classify information and map cryptographic dependencies;
• use approved algorithms, protocols, libraries, and configurations;
• protect private keys with least privilege and appropriate hardware support;
• automate certificate discovery, alerting, renewal, and deployment verification;
• test key recovery and encrypted-backup restoration;
• evaluate supplier controls, contracts, evidence, and exit arrangements;
• prepare incident procedures for compromise, expiry, mis-issuance, and key loss;
• use metrics that measure coverage, exposure, resilience, and response;
• record and review exceptions; and
• plan for algorithm agility and future migration.

Chapter Summary

Cryptographic operations are strategic because they connect technical mechanisms with information value, service availability, supplier dependence, legal duties, and business risk. A reliable programme begins with an accurate inventory of keys, certificates, algorithms, libraries, services, owners, and dependencies. Risk assessment then considers likelihood, impact, exposure, implementation quality, recovery, and the consequences of failure.

Control selection should address the complete operating model: protection, key custody, access, monitoring, rotation, recovery, and retirement. Vendor evaluation must demand evidence about algorithms, key access, logging, incidents, continuity, and exit. Certificate monitoring requires discovery, ownership, renewal, deployment validation, and emergency replacement. Incident response should cover preparation, analysis, containment, eradication, recovery, and lessons learned.

Metrics are valuable when their scope and limitations are clear. Cost-risk comparisons can use expected annual loss, but financial estimates should not obscure legal, ethical, safety, or reputational considerations. Finally, cryptographic lifecycle planning and algorithm agility enable controlled migration rather than crisis-driven replacement.

Key Terms

Cryptographic inventory: A controlled record of cryptographic assets, uses, owners, dependencies, and lifecycle information.

Cryptographic lifecycle: The stages from requirement and design through operation, migration, and retirement.

Residual risk: Risk remaining after controls have been implemented.

Inherent risk: Risk assessed before considering controls.

Key management: Generation, storage, distribution, use, rotation, recovery, revocation, and destruction of keys.

Certificate: A digitally signed document binding an identity to a public key for a defined validity period.

Trust store: A collection of trusted certificates or trust anchors used to validate identities.

Certificate authority: An entity that issues and manages digital certificates.

Private key: Secret cryptographic material used for decryption, signing, or authentication.

Hardware security module: A specialised device that protects keys and performs cryptographic operations.

Cryptographic agility: The ability to replace algorithms, protocols, or keys with limited disruption.

Expected annual loss: Estimated yearly loss calculated from probability multiplied by financial impact.

Risk acceptance: A formal decision to retain a known risk under defined conditions.

Compensating control: An alternative measure that reduces risk when the preferred control cannot be implemented.

Certificate revocation: The process of declaring a certificate invalid before its scheduled expiry.

Authenticated encryption: Encryption that provides confidentiality and integrity protection together.

Supplier assurance: Evidence that a vendor’s security practices meet defined organisational requirements.

Separation of duties: Dividing responsibilities so that one person cannot improperly control an entire sensitive process.

Algorithm migration: Planned replacement of a cryptographic algorithm, protocol, library, or configuration.

Review Questions

Short Answer Questions

1. What is the purpose of a cryptographic inventory?
2. Distinguish inherent risk from residual risk.
3. Name four important stages of key management.
4. Why should certificate monitoring include ownership information?
5. What is cryptographic agility?

Long Answer Questions

1. Explain how an organisation should construct and validate a cryptographic inventory.
2. Discuss the factors that should influence cryptographic control selection.
3. Describe the main areas that should be examined when evaluating a cloud provider’s cryptographic practices.
4. Explain the stages of response to a compromised private key.
5. Discuss why metrics based only on the number of keys rotated may be misleading.

Analytical / Application Questions

1. An organisation discovers that a critical service has an untracked certificate expiring in ten days. Design an immediate response and a long-term governance improvement.
2. A supplier claims that all customer data is encrypted but will not disclose key access, recovery, or incident procedures. Evaluate the claim and recommend procurement conditions.
3. A control costs $30,000 annually and is estimated to reduce the probability of a $600,000 loss from 0.10 to 0.03. Calculate the avoided expected loss and discuss why the calculation alone should not determine the decision.

Multiple Choice Questions with Answers

Question 1

What is the primary purpose of a cryptographic inventory?

A. To list only encryption algorithms

B. To record cryptographic assets, owners, uses, and dependencies

C. To replace incident-response procedures

D. To guarantee that no breach can occur

Correct Answer: B. To record cryptographic assets, owners, uses, and dependencies

Question 2

Which activity most directly reduces the risk of certificate expiry outages?

A. Disabling all certificate validation

B. Recording certificates, owners, validity dates, and renewal alerts

C. Using the same certificate for every service

D. Removing certificate monitoring from change management

Correct Answer: B. Recording certificates, owners, validity dates, and renewal alerts

Question 3

What does residual risk mean?

A. Risk before any controls exist

B. Risk transferred to a supplier only

C. Risk remaining after controls are applied

D. Risk that has been eliminated permanently

Correct Answer: C. Risk remaining after controls are applied

Question 4

Which control is most directly associated with protecting high-value private keys?

A. A public web page

B. A hardware security module

C. A longer asset name

D. An unprotected source-code file

Correct Answer: B. A hardware security module

Question 5

In the expression Risk ≈ Likelihood × Impact, what does impact represent?

A. The consequences if the event occurs

B. The number of algorithms installed

C. The age of a certificate

D. The number of system administrators

Correct Answer: A. The consequences if the event occurs

Question 6

Which question is most useful when evaluating a cloud provider’s key management?

A. Does the provider use the word secure in its marketing?

B. Can provider personnel access plaintext or key material?

C. Does the provider have a modern website?

D. How many colours are used in its dashboard?

Correct Answer: B. Can provider personnel access plaintext or key material?

Question 7

What should normally occur after containment of a compromised private key?

A. Ignore the event if the certificate has not expired

B. Replace affected trust material and remove the cause of compromise

C. Publish the private key for transparency

D. Delete all incident records

Correct Answer: B. Replace affected trust material and remove the cause of compromise

Question 8

Using Expected annual loss = probability × impact, what is the expected annual loss for a 0.08 probability and a $500,000 impact?

A. $4,000

B. $8,000

C. $40,000

D. $580,000

Correct Answer: C. $40,000

Question 9

Which metric is most closely related to cryptographic resilience?

A. Number of colours in security dashboards

B. Percentage of successful encrypted-backup restoration tests

C. Number of employees in the organisation

D. Number of pages in the security policy

Correct Answer: B. Percentage of successful encrypted-backup restoration tests

Question 10

What is the main purpose of cryptographic agility?

A. To prevent all future changes to algorithms

B. To enable controlled replacement of cryptographic mechanisms

C. To eliminate the need for key management

D. To make certificates valid indefinitely

Correct Answer: B. To enable controlled replacement of cryptographic mechanisms