Disclosure: I built ExpiryPulse, a credential expiry tracking tool. The information here applies regardless of what tool you use.
The gap nobody talks about
If your organization handles sensitive data, you're subject to at least one compliance framework that requires credential rotation. NIST SP 800-57 defines cryptoperiods. PCI DSS mandates key replacement. CIS Benchmarks flag unrotated access keys. SOC 2 auditors ask for evidence of credential lifecycle management.
These aren't suggestions. They're requirements.
And yet, the platforms where your credentials live will not tell you when they're about to expire. Not AWS. Not Microsoft. Not Google. You're expected to comply with rotation policies on platforms that give you zero visibility into what's expiring and when.
That's the gap. The frameworks mandate it. The platforms ignore it.
What the frameworks actually say
NIST SP 800-57 (Key Management)
The gold standard for federal and enterprise key management. NIST defines the concept of a "cryptoperiod," the maximum time a cryptographic key should remain active. The recommended period depends on the algorithm, the volume of data processed, and the sensitivity of the information.
NIST doesn't prescribe a single rotation interval. Instead, it requires organizations to define their own cryptoperiods based on risk. The problem is that most teams set the policy and then have no mechanism to enforce it.
NIST SP 800-53 Rev 5, SC-12
The security control that governs cryptographic key establishment and management. SC-12 requires organizations to establish and manage keys "in accordance with organization-defined requirements." It maps directly to CEK-12 (Key Rotation) in the Cloud Security Alliance's Cloud Controls Matrix.
If you're pursuing FISMA, FedRAMP, or CMMC, this control applies to you.
PCI DSS (Requirement 3.6.4)
If you handle payment card data, PCI DSS requires that encryption keys be replaced when they reach the end of their defined cryptoperiod. The standard doesn't specify 90 days or 1 year. It says you define the period and then you enforce it.
Auditors will ask: what is your rotation policy, and how do you know it's being followed?
CIS Benchmarks
The CIS AWS Foundations Benchmark (controls 3.6 and 3.8) recommends enabling KMS key rotation and rotating IAM access keys every 90 days. These are scored controls. If your keys are older than 90 days, you fail the check.
SOC 2 (CC6.1)
SOC 2's Common Criteria 6.1 covers logical access controls, including credential management. Auditors expect to see evidence that credentials are tracked, rotated on schedule, and revoked when no longer needed.
The pattern is the same across every framework: define a policy, enforce it, and prove it.
What the platforms actually do
AWS
IAM access keys have no expiry date. Once created, a key stays valid until you manually deactivate or delete it. AWS recommends rotating every 90 days, but provides no built-in reminder, no notification, and no enforcement mechanism.
To get alerts, you have to build your own pipeline: a Lambda function that queries the IAM Credential Report, calculates key age, and publishes to SNS or SES. Some teams use AWS Config rules to flag non-compliant keys, but that only tells you after the fact that a key is overdue, not before it happens.
The AWS documentation acknowledges this gap and points to custom automation as the solution. For a platform that charges for everything, the absence of a simple "your key is 80 days old" email is striking.
Microsoft Entra ID
App registration client secrets and certificates expire on a date you set when you create them. When that date arrives, Entra ID does not send an email, a Teams notification, or a portal alert. The integration breaks, and you find out because something stops working.
There is a "Recommendations" panel in the Entra admin center that lists expiring credentials, but you have to go look at it. There's also a weekly digest email for Security Administrators, but it's buried among other recommendations and easy to miss.
For a tenant with dozens or hundreds of app registrations, the only reliable approach is a PowerShell script that queries Microsoft Graph and dumps all credential expiry dates to a report. Microsoft does not provide this script. You build it yourself or find one in the community.
Google Cloud Platform
GCP service account keys, by default, never expire. Google recently introduced an optional organization policy (constraints/iam.serviceAccountKeyExpiryHours) that lets you set expiry times on newly created keys. But there is no built-in notification when a key is approaching expiry.
Google's own documentation recommends monitoring keys "using Cloud Asset Inventory" and sending your own alerts. In other words, build a custom pipeline, same as AWS.
The irony is that Google explicitly warns against using service account keys in production and recommends Workload Identity Federation instead. But for teams that need keys for third-party integrations or legacy systems, the reality is that keys exist, they expire (or should), and nobody is watching.
Stripe, Twilio, Slack, and others
Most SaaS API keys don't expire at all. Stripe, Twilio, and Slack all issue long-lived keys that stay valid until manually revoked. There's no rotation reminder, no age warning, and no built-in lifecycle management.
This is by design. These platforms prioritize developer convenience over credential hygiene. But if your compliance framework requires rotation, you need to track these keys yourself, define a rotation schedule, and follow through.
Why this keeps happening
The platforms that issue credentials are not in the business of managing credential lifecycles. AWS wants you to use its services. Microsoft wants you to build integrations. Google wants you to deploy workloads. The credential is a means to an end for them, not a product they actively manage on your behalf.
Enterprise tools like CyberArk, Venafi, and HashiCorp Vault solve parts of this problem, but they come with six-figure price tags, lengthy implementations, and operational overhead that most teams can't justify.
That leaves a gap: you have compliance requirements that demand rotation, platforms that don't help you track it, and enterprise tools that are overkill for your team size.
What actually works
The teams that handle this well do three things.
They maintain a single inventory. Every credential, from every platform, in one place. Not a spreadsheet per team, not a wiki page that nobody updates, not a shared bookmark folder of portal links. One list, with expiry dates, owners, and status.
They automate alerts. Not "check the dashboard weekly" but actual notifications at defined intervals before expiry. Delivered to email, Slack, or Teams, where people already work.
They assign owners. Every credential has a primary and backup owner. When an alert fires, someone specific is responsible for acting on it. No "the team will handle it."
This is not complicated. It's just not built into any of the platforms you use.
Closing the gap
I built ExpiryPulse specifically to fill this gap. One dashboard for credentials across all platforms. Automated alerts at 30, 14, 7, and 1 day before expiry. Primary and backup assignees. Audit trail. CSV import so you can migrate off spreadsheets in minutes.
It doesn't store your actual credentials. Only names and expiry dates.
If you're managing Entra ID app registrations, I've published an open-source PowerShell script that exports all your secret and certificate expiry dates to a CSV you can import directly. More platform scripts are on the way.
Free tier available, no credit card required. expirypulse.dev
Or use a spreadsheet. Use calendar reminders. Use whatever works. The important thing is that you're tracking it somewhere, because the platforms won't do it for you.
Top comments (0)