IAM and Key Vaults: The Mandate, Not the Suggestion

Why identity and access management is the actual perimeter now, where secrets managers fit into that picture, and the real operational tradeoffs of doing either one properly.

Identity and access management gets treated, a lot of the time, as onboarding paperwork — a role to assign on someone's first day and mostly forget about. That's backwards. IAM is the thing standing between an attacker and everything else on this list, and the numbers back that up more directly than most security advice can claim.

The perimeter moved

NIST's Zero Trust Architecture standard, SP 800-207, formalizes something that's been true in practice for a while: the network perimeter isn't where the real boundary is anymore. Every access request gets evaluated on identity as the core control — augmented by device posture and context, enforced close to the resource itself — rather than trusted because it came from inside a firewall. The framework's own summary of the principle: never trust, always verify.

This isn't abstract. It's the direct explanation for why "the request came from inside our VPC" stopped being a meaningful security argument years ago, and why every cheat sheet in this pillar keeps coming back to IAM roles, least privilege, and identity-based access instead of network position.

The stakes, with real numbers

Verizon's 2026 Data Breach Investigations Report — 22,000+ confirmed breaches across 145 countries, their largest dataset to date — recorded something that hadn't happened in the report's 19-year history: vulnerability exploitation overtook stolen credentials as the single most common way attackers get in, at 31% of breaches (a 55% jump year over year).

That's not a signal to relax on credentials, though. Stolen credentials sit at 13% overall (16% including pretexting) — still a massive share — and in Basic Web Application Attacks specifically, stolen credentials remain the single top action, sourced from phishing, infostealer malware, or breach data traded on criminal markets. The honest read: credential theft didn't get less dangerous, exploitation just got worse faster. IAM discipline is still doing real work against roughly one attack in eight, and disproportionately more against the attacks aimed straight at your applications.

What the mandate actually looks like

• Least privilege, enforced, not aspirational. A role should have exactly the permissions its job requires — not *, not "we'll tighten it later." Every cheat sheet in this pillar has repeated this because it's the single highest-leverage control available and the one most commonly skipped for convenience.
• No standing long-lived credentials where a temporary alternative exists. IAM roles and short-lived tokens over hardcoded access keys, every time. A leaked long-lived key is a standing open door until someone notices and rotates it; a leaked short-lived token expires on its own.
• MFA on everything that can authenticate a human, and hardware MFA specifically on anything with root/admin-equivalent power.
• No shared accounts, no shared root/admin logins. Individual identity is what makes an access review or an incident investigation possible at all — a shared login destroys that the moment more than one person has used it.
• Periodic access review, not a one-time grant. Permissions accumulate. Someone changes teams and keeps their old access "just in case." A scheduled review is the only real mechanism that catches this before it becomes the unused, over-permissioned identity an attacker eventually finds.

Where key vaults fit — and where they don't

This is a common conflation worth untangling directly: IAM decides who can access something. A key vault or secrets manager is where the "something" — the actual keys, credentials, and certificates — physically lives. They're complementary, not interchangeable, and a well-run vault is worthless behind a poorly-scoped IAM policy.

The three major cloud secrets services take genuinely different approaches, not just cosmetic ones:

• AWS Secrets Manager is deliberately narrow — it's built for secrets (API keys, database credentials) and delegates other jobs elsewhere: plain configuration to Parameter Store, TLS certificates to AWS Certificate Manager, and raw cryptographic key material to KMS or CloudHSM. It has native rotation integration with RDS, Redshift, and DocumentDB, and logs both management operations and secret-value reads by default once a CloudTrail trail exists.
• Azure Key Vault unifies three object types — secrets, cryptographic keys, and certificates — into one service, with FIPS 140-2 compliant HSM backing available on the Premium tier and through Azure Managed HSM. The gotcha worth knowing: access logging is not on by default. Diagnostic settings have to be explicitly configured per vault before any access is actually logged — an easy thing to assume is automatic and find out later it wasn't.
• GCP Secret Manager stores secrets as binary blobs or text strings, encrypts them with AES-256 before persisting, and tends to have the lowest storage cost at high secret counts — a real factor if the workload involves managing secrets at scale rather than a handful of database credentials.

The tradeoffs

• The vault becomes the highest-value target in the account. Centralizing every secret in one place is exactly what makes secrets manageable — and exactly what makes that vault's own IAM policy the single most important IAM policy anywhere in the environment. A vault with weak access controls around it doesn't reduce risk, it concentrates it.
• Rotation isn't free. Some integrations (Secrets Manager with RDS, for instance) handle rotation natively. Everything else needs a rotation function built and maintained — real ongoing engineering work, not a checkbox.
• Pricing models genuinely diverge at scale. AWS charges per secret per month plus per-API-call; Azure charges per operation rather than per stored secret; GCP's storage cost is lowest for high secret counts. These aren't rounding errors once an environment has hundreds or thousands of secrets — the right choice depends on the actual access pattern, not just which cloud the workload already runs on.
• Strict IAM has a real workflow cost. MFA prompts, conditional access policies, short-lived credentials that require re-authentication — every one of these is friction for a legitimate user, not just an attacker. That friction is the trade being made deliberately, and it's worth being honest that it's a real cost to day-to-day work, not a free win.

Encryption (covered in the companion piece in this pillar) protects data from someone who bypasses access controls. IAM and key vaults are what stand between an attacker and having valid access in the first place — and per Verizon's own numbers, they're still the deciding factor in a meaningful share of real breaches.

Sources: Verizon — 2026 Data Breach Investigations Report · NIST SP 800-207 — Zero Trust Architecture · AWS Secrets Manager vs Azure Key Vault vs GCP Secret Manager — comparison