In this post I'll explore the trade-offs between long and short term canary credentials for threat detection and explain why I think short term credentials are increasingly the right choice for most deployments.
In his recent fwd:cloudsec talk, Nick Frichette highlighted a critical truth about cloud security: threat actors are obsessed with access keys. He reported that 66% of AWS security incidents begin with leaked access keys.
Canary credentials help you catch and quickly shut down these attacks. As demonstrated in Grafana Labs' recent security incident, they can provide the crucial alert that catches a compromise in progress. Equally important, the lack of signal from a canary credential represents a powerful indication that your environment remains uncompromised.
When deploying canary credentials, choosing between short term and long term credentials is an important choice. For some, this may seem surprising, but it's a choice that has real implications for their effectiveness in the immediate and long term.
Understanding the difference
Long term credentials are static access keys, API tokens, or secrets tied to user accounts or service identities. They remain valid indefinitely unless explicitly revoked.
Short term credentials are temporary security tokens with a built in expiration, typically lasting anywhere from 15 minutes to 36 hours depending on the platform.
It's fair to say that in 2025, most of the industry agrees we should avoid introducing long-term credentials and work to remove them from existing systems [3] [4] . When it comes to canary credentials specifically, there are four key criteria that should be considered when making the choice:
4 Considerations
1. Limiting the investigation window
Here’s a quick thought experiment.
You planted a long term canary credential on a server three years ago. Today, three years later, it triggers. What happened?
A.) A threat actor accessed the server in the past 24 hours
B.) The server was compromised two years ago and the credentials are only now being used
C.) The person who set up the canary credentials accidentally left them in their
.bash_history three years ago
Did you get it right? Exactly - it's a trick question, the answer is : Potentially all of the above!
Now if all of those eventualities are possible, I would posit that you may not actually investigate this alert - even if you had all of the telemetry available to do so.
Contrast this to a short term credentials
When short-term credentials trigger, the compromise must have happened recently because the credentials themselves were only just issued. This precise timeframe focuses your incident response on recent activity, changes, and access patterns.
It's the difference between investigating "someone broke in last night" versus "someone may have broken in sometime in the past three years."
2. Environmental realism
For canary credentials to actually work, they need to look legitimate. If an attacker spots credentials that seem obviously out of place, they'll just ignore them.
The industry wide shift toward temporary credentials matters here. If your organisation has moved most workloads to temporary credentials (which all major platforms recommend), then planting long term canary credentials creates an obvious inconsistency. A sophisticated attacker examining the credentials they've found might notice and avoid using them.
This actually is two fold - as your organisation removes their long lived credentials, you don’t want your canary program to be the last remaining reason they exist. This is poor hygiene and may even impact the clean up program.
3. Attacker time pressure
Short term credentials create a "use it or lose it" dynamic that works in defenders' favour.
When an attacker discovers credentials with a visible expiration, they face immediate time pressure. They can't leisurely explore the environment or wait for the right moment to act. They need to use those credentials before they expire. This urgency forces attackers to act quickly, often less carefully, and within a detection window where you're most likely to catch them.
Long term credentials, in contrast, allow attackers to be patient and stealthy, exactly the conditions that let breaches go undiscovered for months. In fact, we’ve spoken to a number of Red Teamers who’ve told us they often assume long term credentials will be a canary, and tend to leave them until the end of the engagement (see 2.!)
4. Automation
A common objection to short-term credentials is that they require automation to deploy effectively. This is true - automating credential issuance requires more upfront work than manually placing a few static keys.
The reality is you should be automating anyway. Manual deployment doesn't scale as your environment grows, and crucially, you'll need to cycle credentials when a canary triggers to maintain detection capability. This makes manual deployments technical debt - even in a perfectly static environment.
With automation, cycling happens seamlessly. The triggered canary gets replaced without manual intervention, maintaining your detection posture while you investigate the alert.
Making the choice
Wrapping up, for most deployments, short term canary credentials are the clear choice for several compelling reasons:
- Limiting the investigation window: Short term credentials give you a precise, narrow timeframe to investigate when they trigger, dramatically simplifying incident response
- Environmental realism: They match the credential types used in modern cloud and identity environments, making them indistinguishable from legitimate infrastructure to attackers
- Attacker time pressure: The "use it or lose it" dynamic forces attackers to act quickly and within your detection window
- You need to automate anyway, why not make the most of it?: While requiring up front investment, automation delivers better operational outcomes and is necessary for any mature canary program
Conclusion
The shift toward short term canary credentials mirrors the broader industry movement away from static, long lived secrets. The same security benefits that make temporary credentials better for production workloads apply equally to detection.
If you're deploying canaries with long term credentials today, consider whether they still match your environment's actual credential usage patterns. And if you're just starting a canary program, building it around short term credentials from day one will set you up for better scalability, stronger detection, and more plausible deception.
If you're curious about how to best deploy canary credentials to match your own environment, book a demo.
Footnotes
[1] Frichette, N. (2025). Sweet Deception: Mastering AWS Honey Tokens to Detect and Outsmart Attackers. fwd:cloudsec 2024.
[2] Grafana Labs. (2025, August 25). Canary tokens: Learn all about the unsung heroes of security at Grafana Labs.
[3] NSA & CISA. (2023). Defending Continuous Integration/Continuous Delivery (CI/CD) Environments.
[4] AWS Well-Architected Framework. SEC02-BP02 Use temporary credentials. Security Pillar.
