{ "api_version": "1", "kind": "dse_post", "self": "https://update.dsesecurity.com/api/v1/posts/coordinate-both-accounts-before-granting-cross-account-kms-use/", "item": { "id": "https://update.dsesecurity.com/updates/coordinate-both-accounts-before-granting-cross-account-kms-use/", "slug": "coordinate-both-accounts-before-granting-cross-account-kms-use", "url": "https://update.dsesecurity.com/updates/coordinate-both-accounts-before-granting-cross-account-kms-use/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/coordinate-both-accounts-before-granting-cross-account-kms-use.md", "json": "https://update.dsesecurity.com/api/v1/posts/coordinate-both-accounts-before-granting-cross-account-kms-use/" }, "title": "Coordinate both accounts before granting cross-account KMS use", "summary": "The owning key policy and caller IAM policy must work together.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "cyber-defense", "label": "Cyber defense", "alt": "Layered glass and metal cyber-defense structure with controlled blue and gold signal paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-20T18:13:41+00:00", "modified_at": "2026-10-20T18:34:29+00:00", "reviewed_on": "2026-10-20", "reading_minutes": 2, "word_count": 241, "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.", "primary_source": { "name": "AWS Documentation", "url": "https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying-external-accounts.html", "published_on": null, "authority": "docs.aws.amazon.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

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

\n

Source facts

\n

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.

\n

Source: AWS Documentation.

\n

Applicability

\n

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

\n

DSE recommendation

\n

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.

\n

Verification

\n

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.

\n

Official reference

\n

AWS Documentation. Reviewed October 20, 2026.

", "content_text": "The owning key policy and caller IAM policy must work together.\nSource facts\nCross-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.\nSource: AWS Documentation.\nApplicability\nThis concerns supported cross-account KMS API use, with additional requirements for each integrated AWS service.\nDSE recommendation\nDSE 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.\nVerification\nProposed 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.\nOfficial reference\nAWS Documentation. Reviewed October 20, 2026.", "content_markdown": "The owning key policy and caller IAM policy must work together.\n\n## Source facts\n\nCross-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.\n\nSource: [AWS Documentation](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying-external-accounts.html).\n\n## Applicability\n\nThis concerns supported cross-account KMS API use, with additional requirements for each integrated AWS service.\n\n## DSE recommendation\n\nDSE 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.\n\n## Verification\n\nProposed 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.\n\n## Official reference\n\n[AWS Documentation](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying-external-accounts.html). Reviewed October 20, 2026." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/coordinate-both-accounts-before-granting-cross-account-kms-use/", "url": "https://update.dsesecurity.com/updates/coordinate-both-accounts-before-granting-cross-account-kms-use/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-20" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/coordinate-both-accounts-before-granting-cross-account-kms-use/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Cybersecurity", "item": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "ListItem", "position": 3, "name": "Coordinate both accounts before granting cross-account KMS use", "item": "https://update.dsesecurity.com/updates/coordinate-both-accounts-before-granting-cross-account-kms-use/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/coordinate-both-accounts-before-granting-cross-account-kms-use/#article", "identifier": "https://update.dsesecurity.com/updates/coordinate-both-accounts-before-granting-cross-account-kms-use/", "url": "https://update.dsesecurity.com/updates/coordinate-both-accounts-before-granting-cross-account-kms-use/", "headline": "Coordinate both accounts before granting cross-account KMS use", "description": "The owning key policy and caller IAM policy must work together.", "abstract": "The owning key policy and caller IAM policy must work together.", "articleBody": "The owning key policy and caller IAM policy must work together.\nSource facts\nCross-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.\nSource: AWS Documentation.\nApplicability\nThis concerns supported cross-account KMS API use, with additional requirements for each integrated AWS service.\nDSE recommendation\nDSE 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.\nVerification\nProposed 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.\nOfficial reference\nAWS Documentation. Reviewed October 20, 2026.", "datePublished": "2026-10-20T18:13:41+00:00", "dateModified": "2026-10-20T18:34:29+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/coordinate-both-accounts-before-granting-cross-account-kms-use/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/coordinate-both-accounts-before-granting-cross-account-kms-use/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Coordinate both accounts before granting cross-account KMS use" }, "articleSection": [ "Cybersecurity", "IT" ], "keywords": [ "Cybersecurity", "IT", "Guide", "Information priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "wordCount": 241, "timeRequired": "PT2M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "AWS Documentation", "url": "https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying-external-accounts.html" } } ] } }