# Ensure access keys are rotated every 90 days or less (Storage access keys)

- Source: https://support.icompaas.com/support/solutions/articles/a_1786022817728317-ensure-access-keys-are-rotated-every-90-days-or-less-storage-access-keys
- Section: [Solutions](https://support.icompaas.com/support/solutions) › [Utho Cloud](https://support.icompaas.com/support/solutions/c_1786022244474917) › [Utho Checks](https://support.icompaas.com/support/solutions/folders/utho-checks)
- Last updated: 2026-08-06
- Publisher: iCompaas, Inc. (https://www.icompaas.com)

## Description

Utho Object Storage is accessed programmatically through access keys: each key is an access-key / secret-key pair that authenticates S3-compatible requests to your buckets. Utho generates the pair when you create the key and shows the secret only once, and it grants a per-key permission level (Read, Write, or Read-Write) on the buckets it can touch.

This control checks that those access keys are rotated on a fixed schedule of 90 days or less — that is, a new key is created, all applications are cut over to it, and the superseded key is disabled and deleted. Utho has no built-in key expiry or auto-rotation, so rotation is an operational discipline you enforce, not a setting you toggle.

A key is 'stale' for this check when its creation date is older than 90 days and it is still active.

-   Long-lived storage credentials that never expire and are never revoked
    
-   Access/secret pairs leaked in Git history, CI logs, mobile apps, or a former employee's laptop that still authenticate
    
-   Absence of a rotation process for object-storage credentials
    

## Rationale

A storage access key that never expires is a permanent skeleton key. If it leaks in a commit, a build log, a container image layer, or an ex-employee's machine, an attacker can list, read, and overwrite every object the key is permissioned for — indefinitely — because no rotation window ever cuts the leaked credential off.

Rotating every 90 days or less bounds that exposure: even an undetected leak stops working within one rotation cycle, and the act of rotating forces you to inventory exactly which applications hold which credentials.

-   Limits the useful lifetime of any leaked or stolen key to at most one rotation window
    
-   Forces a periodic inventory of who/what holds storage credentials
    
-   Reduces standing blast radius from a single compromised secret
    

## Impact

Pros:

-   Leaked credentials become useless within the rotation window
    
-   Regular create-swap-retire practice keeps a current inventory of key consumers
    
-   Retiring old keys removes orphaned credentials from former apps and staff
    

Cons:

-   Every dependent app, backup job, and CI/CD pipeline must be updated with the new pair each cycle, risking outage if one is missed
    
-   The secret key is shown only once, so a botched copy means re-issuing again
    
-   Utho has no native auto-rotation, so the schedule must be driven by your own reminders or scripts
    

## Default Value

Not documented by Utho; verify in your account — Utho displays each object-storage access/secret pair only once at creation and provides no built-in key expiry or auto-rotation, so keys never rotate unless you rotate them manually.

## Pre-Requisite

-   Utho console access to the account/team that owns the Object Storage buckets
    
-   An inventory of every application, backup job, and pipeline that uses each access key (so you can cut them over)
    
-   A secure place to capture the new secret key, which Utho shows only once
    
-   For any API automation: a Utho Api Token (Authorization: Bearer) generated in the console
    

## Remediation

### Test Plan

Using the Utho Console:

1.  Sign in to the Utho console and open Object Storage.
    
2.  Select the bucket and open its Access Keys / permissions view.
    
3.  For each listed access key, note the creation/issue date and whether it is still enabled.
    
4.  Compare each active key's age against today.
    
5.  Pass: every active access key was created within the last 90 days and no disabled/superseded keys remain that could still authenticate.
    
6.  Fail: any active access key is older than 90 days, or retired keys have not been deleted.
    

Using the Utho API:

Utho exposes a Developer API v2 (api.utho.com/v2) that can list object storage and access keys, but the exact object-storage access-key read path could not be verified against Utho's published API reference; treat the console as authoritative and confirm the endpoint at utho.com/api-docs before scripting.

### Implementation Steps

Using the Utho Console:

1.  Open Object Storage in the Utho console and go to the bucket's access-keys / permissions section.
    
2.  Create a new access key (provide a name) and securely copy the new access key and secret key — Utho displays the secret only once.
    
3.  Grant the new key only the permission level it needs (Read, Write, or Read-Write) via Update Permission.
    
4.  Roll the new access/secret pair into every dependent application, backup job, and CI/CD pipeline, then verify traffic succeeds on the new key.
    
5.  Disable the old key and confirm nothing breaks, then delete it so the retired credential can no longer authenticate.
    
6.  Record the rotation date and repeat this create-swap-retire cycle at least every 90 days (drive the reminder with your own scheduler since Utho has no auto-expiry).
    

Using the Utho API:

Access-key rotation is performed in the Utho console. Utho's Developer API (utho.com/api-docs) can manage object storage and access keys programmatically, but the exact create/delete access-key paths could not be confirmed against the published spec, so no commands are given here — verify the endpoints in Utho's API reference before automating.

### Backout Plan:

1.  If applications fail after cutover, re-enable the previous access key (do not delete it until the new key is proven) so traffic can fall back immediately.
    
2.  Point the affected application back to the old access/secret pair and confirm service is restored.
    
3.  Diagnose why the new key failed (wrong permission level, mis-copied secret, un-updated config), fix it, and retry the cutover.
    
4.  Only delete the old key once every consumer is confirmed working on the new key.
    

## References:

1.  [Utho Docs – Update Storage Access](https://utho.com/docs/products/storage/object-storage/how-tos/update-storage-access/)
    
2.  [Utho Docs – Object Storage Access Control](https://utho.com/docs/products/storage/object-storage/manage-object-stroage/access-control/)
    
3.  [Utho Docs – Object Storage FAQs](https://utho.com/docs/products/storage/object-storage/faqs/)
    
4.  [Utho Developer API reference](https://utho.com/api-docs/)

## Related compliance guidance

- [SOC 2 compliance: a practical implementation guide for cloud-native SaaS teams](https://support.icompaas.com/compliance/soc-2-trust-services-criteria): Configuration checks like this one are the technical half of a SOC 2 / ISO 27001 programme — the guide shows where they fit, what else an auditor expects, and how to evidence them.
- [ISO/IEC 27001:2022 compliance: a practical implementation guide](https://support.icompaas.com/compliance/iso-27001-2022): ISO 27001 Annex A.8 (technological controls) is where cloud hardening evidence lands; the guide shows how to run the ISMS around it.