Key Revocation
Specification
Define, implement and evaluate processes, procedures and technical measures to revoke and remove cryptographic keys prior to the end of its established cryptoperiod, when a key is compromised, or an entity is no longer part of the organization, which include provisions for legal and regulatory requirements.
Threat coverage
Architectural relevance
Lifecycle
Data storage
Guardrails
Not applicable
Orchestration, AI Services supply chain, AI applications
Operations, Maintenance, Continuous monitoring, Continuous improvement
Archiving, Data deletion, Model disposal
Ownership / SSRM
PI
Shared Cloud Service Provider-Model Provider (Shared CSP-MP)
The CSP and MP are jointly responsible and accountable for the design, development, implementation, and enforcement of the control to mitigate security, privacy, or compliance risks associated with Large Language Model (LLM)/GenAI technologies in the context of the services or products they develop and offer.
Model
Owned by the Model Provider (MP)
The model provider (MP) designs, develops, and implements the control as part of their services or products to mitigate security, privacy, or compliance risks associated with the Large Language Model (LLM). Model Providers are entities that develop, train, and distribute foundational and fine-tuned AI models for various applications. They create the underlying AI capabilities that other actors build upon. Model Providers are responsible for model architecture, training methodologies, performance characteristics, and documentation of capabilities and limitations. They operate at the foundation layer of the AI stack and may provide direct API access to their models. Examples: OpenAI (GPT, DALL-E, Whisper), Anthropic(Claude), Google(Gemini), Meta(Llama), as well as any customized model.
Orchestrated
Shared Orchestrated Service Provider-Application Provider (Shared OSP-AP)
The OSP and AP are jointly responsible and accountable for the design, development, implementation, and enforcement of the control to mitigate security, privacy, or compliance risks associated with Large Language Model (LLM)/GenAI technologies in the context of the services or products they develop and offer.
Application
Owned by the Application Provider (AP)
The Application Provider (AP) is responsible for the design, development, implementation, and enforcement of the control to mitigate security, privacy, or compliance risks associated with Large Language Model (LLM)/GenAI technologies in the context of the services or products they develop and offer. The AP is responsible and accountable for the implementation of the control within its own infrastructure/environment. If the control has downstream implications on the users/customers, the AP is responsible for enabling the customer and/or upstream partner in the implementation/configuration of the control within their risk management approach. The AP is accountable for carrying out the due diligence on its upstream providers (e.g MPs, Orchestrated Services) to verify that they implement the control as it relates to the service/product develop and offered by the AP. These providers build and offer end-user applications that leverage generative AI models for specific tasks such as content creation, chatbots, code generation, and enterprise automation. These applications are often delivered as software-as-a-service (SaaS) solutions. These providers focus on user interfaces, application logic, domain-specific functionality, and overall user experience rather than underlying model development. Example: OpenAI (GPTs,Assistants), Zapier, CustomGPT, Microsoft Copilot (integrated into Office products), Jasper (AI-driven content generation), Notion AI (AI-enhanced productivity tools), Adobe Firefly (AI-generated media), and AI-powered customer service solutions like Amazon Rufus, as well as any organization that develops its AI-based application internally.
Implementation guidelines
Auditing guidelines
1. Verify that the CSP defines, implements, and evaluates processes, procedures, and technical measures to revoke and remove cryptographic keys prior to the end of their cryptoperiod when they are no longer needed, compromised, or associated with entities no longer authorized, including keys stored in cloud-native KMS, customer-scoped HSMs, or infrastructure secrets stores. 2. Confirm that key revocation criteria are documented, including conditions such as key compromise, system decommissioning, cryptoperiod expiration, and personnel offboarding and that these criteria are reviewed periodically. 3. Verify that key revocation is supported by secure, automated tooling (e.g., cloud KMS policies, API-driven key invalidation, secrets rotation frameworks) and that manual processes follow approval-based workflows. 4. Review cloud infrastructure configurations to ensure revoked keys are promptly removed from caches, metadata services, memory, and other runtime environments where keys may have been provisioned. 5. Confirm that permissions to initiate key revocation are restricted to authorized roles (e.g., cloud security operations, cryptography service owners) and are governed by access control policies and change approval processes. 6. Validate that CSP keys associated with AI workloads (e.g., encrypted model storage, inference logging, or prompt data encryption) are revoked according to organizational policies and that dependencies in AI pipelines are updated accordingly. 7. Review logs for key revocation activities to confirm auditability, including key ID, reason for revocation, identity of the requestor, system components affected, and timestamp of revocation. 8. Confirm that downstream cloud services or tenants using the revoked key (e.g., APs, AICs) are automatically notified or updated to prevent reliance on invalid key material and that fallback behaviors are clearly defined. 9. Verify that revoked keys are archived or securely deleted according to the CSP’s cryptographic lifecycle policies, retention requirements, and legal or contractual obligations. 10. Confirm that the CSP coordinates with upstream service providers (e.g., hardware root key issuers, SaaS integrations) and downstream customers to manage shared key revocation events in a way that preserves service continuity and security. From CCM: 1. Examine the organization procedures and confirm the existence of a key revocation process. 2. Identify a population of keys and confirm that they are captured within the key revocation process. 3. Confirm that a list of entities that are no longer part of the organization is maintained.
Standards mappings
No Mapping for ISO 42001 ISO 27001: A.8.24 ISO 27002: 8.24
Addendum
Add a control requiring AI systems to define, implement, and evaluate processes, procedures, and technical measures to revoke and remove cryptographic keys prior to the end of their cryptoperiod, upon compromise, or when an entity leaves the organization, including provisions for legal and regulatory requirements, addressing ISO 42001:2023’s lack of specific key revocation mandates, enhancing ISO 27001 (A.8.24) and ISO 27002 (8.24).
No Mapping
Addendum
Cover the AICM control.
No Mapping
Addendum
No (implicit/explicit) reference to cryptography, encryption, or key management is made in the NIST AI 600-1 standard, let alone to the specific requirement of key revocation and removal.
CRY-04
Addendum
N/A
AI-CAIQ questions (1)
Are cryptographic keys revoked and removed before the end of the established cryptoperiod (when a key is compromised, or an entity is no longer part of the organization) per defined, implemented, and evaluated processes, procedures, and technical measures which include legal and regulatory requirement provisions?