The algorithm is not your problem. AES-256 has never been broken in production. TLS 1.3 is sound. RSA, when implemented correctly, holds. The mathematics of modern encryption are robust enough that attacking them directly is, for practical purposes, not a viable strategy for any adversary below nation-state level. If your data was stolen, the encryption almost certainly did not fail.

What failed was probably key management, and that is an unglamorous, under-resourced, and persistently underestimated part of security infrastructure at most organizations.

The Lock Is Strong. The Key Is Hanging by the Door.

The pattern is consistent across major breaches: attackers do not break encryption, they obtain credentials. The 2019 Capital One breach, which exposed more than 100 million customer records, was not a cryptographic failure. It was a misconfigured firewall combined with an overly permissive IAM role, which let an attacker retrieve credentials from an AWS metadata service and use those credentials to pull data from S3. The data may have been encrypted at rest. The attacker had the key.

This is the central irony of enterprise security spending. Companies pour budget into encryption tooling, compliance certifications, and penetration testing that focuses on perimeter defenses, while their secrets sprawl across codebases, environment variables, CI/CD pipelines, and shared Slack messages. HashiCorp’s own research has consistently found that hardcoded credentials in source code represent one of the most common and persistent security failures in otherwise sophisticated engineering organizations.

The problem is not ignorance of best practices. Most engineers know that API keys do not belong in version control. The problem is friction. When rotating a secret is harder than hardcoding it, and when the cost of that shortcut is invisible until a breach occurs, the shortcut wins every time.

Diagram showing the lifecycle of a cryptographic credential drifting from careful management into neglect and eventual compromise
Key and certificate lifecycle failures are almost never cryptographic. They are operational.

What Good Key Management Actually Looks Like

Key management done properly has several non-negotiable properties: centralized storage with auditable access logs, automatic rotation on a defined schedule, environment-specific secrets that are never shared across production and development, and short-lived credentials wherever possible.

The last point deserves more attention than it gets. Static, long-lived API keys are a liability that compounds over time. Every month a key exists is another month of opportunity for it to leak through an employee departure, a misconfigured logging pipeline, or a vendor compromise. AWS IAM roles with temporary credentials, or tools like Vault’s dynamic secrets (which generate a credential on demand and expire it after use), eliminate entire categories of risk. The key that does not persist cannot be stolen and used later.

AWS Secrets Manager, HashiCorp Vault, and Azure Key Vault have made centralized secret management accessible to organizations that are not running security teams of dozens. The tooling is mature. The patterns are well documented. The barrier is organizational, not technical: someone has to own the migration, enforce the standards, and make rotation cheaper than neglect.

That ownership problem is where most companies actually fail. Security teams issue policies. Engineering teams ship features. Nobody is specifically accountable for auditing whether the secrets policy is actually followed in every service, every repository, and every third-party integration.

Certificate Management Is the Same Problem Wearing a Different Hat

If API key hygiene is underinvested, TLS certificate management is actively neglected at a remarkable number of organizations. Certificate expiration outages are embarrassingly common, and they happen not because the technology is hard but because certificate lifecycle management requires sustained attention rather than one-time setup.

In 2020, Microsoft Teams experienced a significant outage traceable to an expired certificate. In 2021, a certificate expiration contributed to failures in Spotify’s infrastructure. These are not small companies with limited resources. They are organizations with large security and infrastructure teams that still allowed certificates to lapse because certificate management was either nobody’s specific job or was tracked in a spreadsheet that someone forgot to update.

Automated certificate management through tools like Let’s Encrypt with ACME-based renewal, or AWS Certificate Manager for Amazon-hosted infrastructure, solves this problem almost entirely. The fact that manual certificate management still exists in production environments at scale is a choice, usually made by inertia rather than deliberate preference.

The Compliance Trap

Some of the worst key management practices exist inside organizations that have achieved SOC 2 Type II certification or PCI DSS compliance. Compliance frameworks set floors, not ceilings, and the floor for secret management in most frameworks is not especially high. An organization can be fully compliant and still have dozens of long-lived API keys scattered across environment configs, still be rotating database passwords manually on an annual basis, and still have no automated alerting when a credential is accessed from an unusual IP.

Certification gives procurement teams confidence and legal teams comfort. It does not mean the actual security posture is strong. A company that treats compliance as the goal has fundamentally misunderstood the exercise. The question worth asking is not “are we compliant” but “if an attacker had fifteen minutes inside our infrastructure, what could they reach, and how quickly would we know.”

Where to Actually Start

Organizations that want to improve should resist the temptation to buy a new tool before auditing what they already have. The first step is inventory: enumerate every secret in use, where it lives, when it was last rotated, and who has access. For most engineering organizations, this audit is itself a clarifying and uncomfortable exercise.

From there, the priority order is straightforward. Eliminate hardcoded secrets in source code first, because they are the highest-probability leak vector and the easiest to address with automated scanning tools like GitGuardian or truffleHog. Move secrets into a centralized store second. Implement rotation for high-value credentials third. Build alerting for anomalous access patterns fourth.

None of this is exotic. The tools exist, the patterns are proven, and the cost of implementation is far lower than the cost of a breach. The encryption holding your data is almost certainly solid. The question is whether the keys to that encryption are managed with anything close to the same rigor. For most organizations, honestly assessed, the answer is no.