# Coordinate both accounts before granting cross-account KMS use

> The owning key policy and caller IAM policy must work together.

- Canonical URL: https://update.dsesecurity.com/updates/coordinate-both-accounts-before-granting-cross-account-kms-use/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-10-20T18:13:41+00:00
- Modified: 2026-10-20T18:34:29+00:00
- Last reviewed by DSE: 2026-10-20
- Resource type: Guide
- DSE priority: Information
- Topics: Cybersecurity, IT
- Reading time: 2 minutes

## What you need to know

The owning key policy and caller IAM policy must work together.

## Potentially affected

This concerns supported cross-account KMS API use, with additional requirements for each integrated AWS service.

## DSE recommendation

DSE recommends identifying the key owner and external-role owner before troubleshooting.

## Article

The owning key policy and caller IAM policy must work together.

## Source facts

Cross-account KMS access requires permission in the owning key policy and an IAM policy in the external account. Neither policy alone is sufficient. Only documented operations support cross-account permission; an arbitrary administrative operation remains unavailable even if a policy names it. KMS records relevant cross-account operations in both accounts’ audit logs.

Source: [AWS Documentation](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying-external-accounts.html).

## Applicability

This concerns supported cross-account KMS API use, with additional requirements for each integrated AWS service.

## DSE recommendation

DSE recommends identifying the key owner and external-role owner before troubleshooting. Agree the specific operations and full key ARN, then review both sides of the authorization. Avoid treating a permissive key policy as permission for every external user. Record how the grant will be removed and who will investigate failures. Check regional availability and service-specific integration requirements rather than copying a generic cryptographic-access example into a complete application design. Use one shared access matrix showing the caller role, intended cryptographic operation and owning key. Have both account owners approve the same matrix and identify which side will collect the first diagnostic evidence when the integration fails.

## Verification

Proposed verification: exercise a supported operation with disposable data through the intended external identity, confirm an unapproved identity is denied and inspect both accounts’ audit evidence. Review an unsupported administrative operation against the reference instead of widening the policies to make it work.

## Official reference

[AWS Documentation](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying-external-accounts.html). Reviewed October 20, 2026.

## Primary reference

- Name: AWS Documentation
- Authority: docs.aws.amazon.com
- URL: https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying-external-accounts.html
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Coordinate both accounts before granting cross-account KMS use,” DSE Security, https://update.dsesecurity.com/updates/coordinate-both-accounts-before-granting-cross-account-kms-use/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.