A third-party application only supports static AWS access keys and can't use an instance profile or role. How do you handle this without abandoning least privilege entirely?

Accept that a static credential is genuinely required here, but contain the damage on every other axis: create a dedicated IAM user scoped to only the specific actions/resources that application needs (never reused for anything else), rotate its access keys on an automated schedule rather than leaving them static indefinitely, and monitor its usage specifically so an anomaly is caught quickly — treating the unavoidable static credential as a contained, actively-managed exception rather than accepting broad, unmonitored access as the price of the integration.

When a vendor's software genuinely can't use temporary, role-based credentials, the goal shifts from "eliminate static credentials" (not achievable here) to "minimize and contain the blast radius of the one static credential that's unavoidable." Several concrete practices accomplish this:

Scope tightly, dedicate exclusively: create an IAM user used by nothing except this one integration, with a policy granting only the specific actions and resource ARNs the application actually needs — not a broad managed policy reused from elsewhere. This bounds what a leaked key can actually do, even though it can't prevent the leak itself.

Automate rotation: static doesn't have to mean permanent. Build a scheduled rotation (e.g. a Lambda function on a schedule, or AWS's own credential rotation tooling where applicable) that generates new access keys, updates the application's configuration with them, and deactivates the old key after a safe overlap window — reducing the window during which any single leaked key remains valid, even if the credential type itself is static.

Monitor usage specifically: set up CloudTrail-based alerting scoped to this specific IAM user — unexpected API calls, unexpected source IPs, or unexpected times of activity are a much stronger signal when watched for one narrowly-scoped user than buried in account-wide activity. This is where a lot of the actual risk reduction comes from: catching misuse quickly rather than assuming it won't happen.

Isolate blast radius further: where possible, run the application in a way that limits what a compromised key could reach even within its granted permissions — a separate AWS account for this integration specifically (via AWS Organizations) is the strongest version of this, since even a fully-compromised key is contained to that account's resources rather than the whole organization's.

Push the vendor: if there's any realistic chance the vendor will add role-based credential support, filing that request costs little and occasionally succeeds — worth doing in parallel even while implementing the containment measures above, since it's the only path that actually eliminates the static credential rather than just managing its risk.

The overall posture: a static credential forced by a vendor constraint isn't a failure of least privilege — it's a case where least privilege has to be expressed through scope, rotation, and monitoring instead of through "no long-lived credential exists at all," which is the ideal but not always achievable one.

• When temporary credentials genuinely aren't an option, contain risk through tight scoping, automated rotation, and dedicated monitoring rather than accepting broad, unmanaged access.
• A dedicated IAM user used by nothing else bounds the blast radius of a leak, even though it can't prevent one.
• Automated rotation reduces the exposure window of a static credential, even though the credential type itself stays static.
• A separate AWS account for the integration is the strongest containment measure, limiting a compromised key's reach to that account alone.

• AWS: IAM access keys best practices
• AWS: Rotating access keys
• AWS: Logging IAM and AWS STS API calls with CloudTrail