Note:
- In KeySafe documentation, ‘authentication’ refers to how Box proves its identity to your KMS when performing encrypt and decrypt operations. It does not refer to Box user login, SSO, or application sessions.
- This article covers keyless authentication for AWS KMS. Contact your Box representative for the latest information on GCP Cloud KMS keyless authentication availability.
What keyless authentication is
With keyless authentication, Box proves its identity to your KMS without any customer-issued credentials:- You grant Box’s cloud identity access in your CMK key policy - a standard, auditable AWS-native mechanism.
- Box authenticates to your KMS using short-lived credentials obtained through its own cloud workload identity. No customer-issued credentials are involved.
- Your KMS key policy controls access. You can review and modify it at any time directly in AWS.
| Previous authentication | Keyless authentication | |
|---|---|---|
| How Box authenticates | Long-lived customer AWS credentials stored by Box | Box’s cloud identity using short-lived credentials |
| What you provide | IAM access keys, role ARNs, or credential material | CMK key policy granting access to Box’s identity |
| What Box stores | Your AWS access key and secret, or role details | A key identifier and configuration metadata only |
| Credential rotation | Required periodically; coordinated with Box credentials | Not required - no customer credentials to rotate |
| Revocation method | Delete IAM users/keys and coordinate with Box | Edit your KMS key policy directly in AWS |
Previous authentication methods
Historically, KeySafe on AWS required customers to share long-lived AWS credentials or establish standing IAM trust with Box. Regardless of the specific mechanism used - dedicated IAM user, cross-account role assumption, or key-policy with stored credential chains - these approaches all required Box to store customer credential material that remained valid until manually rotated. This created operational overhead: credential rotation required coordinated steps between your team and Box, each region could multiply separate credential sets, and revoking access required bilateral coordination rather than a unilateral policy change.Benefits of keyless authentication
- All KMS access is logged in your AWS CloudTrail — the same audit surface as any other KMS consumer.
- Aligns with zero-trust and short-lived credential best practices.
- Simplifies audit narratives: no third-party credentials to rotate or manage.
- Multi-region deployments use a single trust model (key policy per regional CMK) rather than separate credential sets per region.
- Reduces coordination touchpoints between your team and Box for routine security operations.
Multi-region considerations
For enterprises using multi-region AWS KMS, keyless authentication simplifies operations by replacing per-region credential management with a consistent key-policy-based trust model. Each regional CMK receives a key policy statement granting access to Box’s identity, eliminating the need for separate credentials in each region.Upgrading to keyless authentication
Upgrading from a previous authentication method to keyless is an authentication-only change:- Your CMK does not change.
- Your encrypted data does not change.
- No re-encryption (rekey) is required by default. Key rotation - replacing or migrating the CMK itself - is independent of authentication method and is unaffected by this upgrade.
Revoking Box access
With keyless authentication, you revoke Box’s access by editing your KMS key policy in AWS to remove the statement that grants access to Box’s identity. Once removed:- All file operations (upload, download, preview) for your enterprise will fail.
- Content is not deleted - it remains encrypted and intact.
- Access can be restored by re-adding Box’s identity to the key policy.