Treat a push registration as stale if its app instance has not connected for a month, delete any registration your push provider reports as invalid, and store a last-seen timestamp so you can prune on a schedule. Android registrations also expire after 270 days of inactivity.
Definition
A registration token, or Firebase Installation ID in newer Firebase terms, identifies one app instance on one device so your server can address a push message to it. Firebase documentation describes stale registrations as those tied to inactive devices that have not connected for over a month, and says they are unlikely to ever receive a message.
Why a device goes quiet: it was lost, destroyed, stored and forgotten, or the app was uninstalled.
Why this is a security and privacy issue too
A table of tokens is a list of device identifiers tied to user accounts. Keeping dead ones is data you hold without a purpose. Pruning them supports data minimization and shrinks what an attacker gets from a database leak. It also keeps your delivery numbers honest. Firebase notes that sending to stale registrations can show up as a large but not actually valid drop in delivery rates.
What the provider tells you
According to Firebase documentation:
| Platform | Expiry behaviour |
|---|---|
| Android | Registration inactive for 270 days is treated as expired and garbage collected; sends to it are rejected |
| iOS | FCM relies on the underlying push service, which does not have the same 270 day inactivity expiry, so you should prune proactively |
| Default stale threshold | One month without the app instance connecting; you can choose a different one |
Detect invalid responses and delete those registrations. With the HTTP v1 API, an UNREGISTERED response (HTTP 404) indicates a dead registration. INVALID_ARGUMENT (HTTP 400) can also be a payload problem, so treat it as invalid only when the payload is known to be good.
A pruning routine
- Store a last-refreshed timestamp for each token, and have the app refresh and upload its registration on each launch.
- On every send, delete tokens that come back as unregistered.
- Run a scheduled job that removes tokens not refreshed within your threshold, one month by default or a longer window you can justify.
- Delete all tokens for a user when they sign out everywhere or close the account.
- Log counts of tokens pruned, not the tokens themselves.
- Review the threshold if your app is used rarely, for example a seasonal app, so you do not drop real users.
Handling tokens as sensitive data
Treat tokens as identifiers: restrict database access, keep them out of logs, and do not put them in analytics events. A stolen token is not enough to send you messages without your server credentials, but it ties a device to an account. See what to log and what to scrub for the similar web push case.
Where Safeguard fits
Safeguard's compliance and evidence automation helps you document retention rules and show that they run. Its dependency scanning covers the messaging SDKs in your apps. The free scan is at https://gold.safeguard.sh/scan.
Quick check
Is one month too aggressive?
It is Firebase's default threshold, and you can choose your own. Longer windows suit apps used infrequently.
Does a 404 from the send API always mean delete?
An UNREGISTERED 404 means the registration is dead. A 400 INVALID_ARGUMENT needs a check, since a bad payload can cause it too.
Sources
Last reviewed: 19 October 2026.
