Run a small validation job that proves each credential can authenticate, using read-only checks or a test track, and never touches a production release. Do it on a schedule and after any rotation, so a broken or expired key is found on a quiet Tuesday rather than during an urgent fix.
Why bother
Release credentials fail quietly: a key is rotated and the pipeline variable is not, a service account loses a permission, or a session expires. If the first time you learn this is when a security fix needs to ship, the fix waits. A scheduled check turns that into a ticket.
What the tools give you
The fastlane Play Store documentation includes a validation action that tests the connection to Google Play using the downloaded JSON key, and it suggests running it before adding the key path to your Appfile. That is exactly a no-release check. Google's own guide describes the service account setup and says the credentials must be kept in a secure environment.
For Apple, the fastlane App Store Connect API page describes an API key made of a .p8 file, a key ID and an issuer ID that create a short-lived token, with a documented maximum token duration of 1,200 seconds. A job that builds a token and makes one harmless read request, such as fetching the latest build number, proves the key works. The docs list an action for retrieving the latest build number among tools that accept API keys.
A validation job
| Step | What it proves |
|---|---|
| Load credentials from the secret manager | The variables exist and are mapped |
| Validate the Play key | The service account can authenticate |
| Read the latest build number from the Apple side | The App Store key and role work |
| Read version codes from a testing track on Play | The permission set includes at least reading |
| Report pass or fail, without printing secrets | You find out early |
Run it daily or weekly, and always after rotating a key.
Keep the check low-privilege
The validation job should use the same credentials as the real lanes, otherwise it proves nothing, but it should run on a schedule trigger from the default branch only and never on pull requests. It is a good place to apply the split described in our post on Play service accounts with least privilege: the beta account is tested daily, the production account is tested only inside the protected release job.
When you do need a real upload test
To test the full path, upload to an internal testing track or a TestFlight group and not to production. Both are staged away from store customers. Name the build clearly as a pipeline test and remove it after.
What to alert on
- Authentication failures, which usually mean rotation or removal.
- Permission errors, which mean someone changed a role.
- Silence. If the job stops running, nobody notices a thing, so alert when the last success is older than your interval.
After rotation
Rotate the secret, run the validation job at once, and only then remove the old credential. If the new one fails you still have the old one to fall back on.
Try it yourself
Open the demo and look at how a scheduled check raises a finding when something changes. A credential check job works the same way.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard does not hold store keys. It covers the code side: SBOM and dependency scanning, reachability analysis and policy gates. Try a free scan.
Quick check
Does validating a key count as a release?
No. A validation or read-only call authenticates but does not publish anything.
Should the check run on pull requests?
No. Run it from the default branch or on a schedule, so untrusted code never reaches the credentials.
Sources
- fastlane docs: upload_to_play_store
- fastlane docs: using the App Store Connect API
- Google Play Developer API: getting started
Last reviewed: 19 October 2026.
