When a critical vulnerability lands while you are away from your desk, spend the first hour on four questions: do we run it, is it reachable, is it exploited, and what is the fix. You can start from any device. Safeguard's mobile app is in early access (beta), so this article describes the routine, not its screens.
What the mobile app is, and what this article will not claim
Safeguard lists its iOS and Android app as early access, a beta. This article does not describe individual screens, buttons or tasks in the app, because they are not documented in the sources we could check. Look at safeguard.sh/download for the current state, and ask your Safeguard contact what the beta supports before you build an on-call routine around it.
Everything below works with a laptop, a phone browser, or the Safeguard web app at app.safeguard.sh, which is chat-first.
Minute 0 to 10: do we run it?
Read the advisory first, not a summary. Check the vulnerable product and version ranges. Then check your inventory: which services, images and hosts contain that component? If you maintain SBOMs for your products, this is a lookup. If you do not, this is the moment you learn what that gap costs.
Write down the answer in one line: "Affected: three services, two images" or "Not found."
Minute 10 to 25: is it reachable and exposed?
A vulnerable library in a service that never calls the vulnerable function is lower urgency than one on a path your code uses. Reachability analysis answers that, and so does reading the advisory's conditions. Note also whether the affected service is internet-facing.
Minute 25 to 40: is it being exploited?
Check CISA's Known Exploited Vulnerabilities catalog, which CISA describes as the authoritative source of vulnerabilities exploited in the wild and which organizations should use as an input to prioritization. Also read the vendor advisory for exploitation notes. A critical score with no known exploitation and no reachable path may be tomorrow's work. A KEV entry on an exposed service is now's work.
Minute 40 to 55: what is the fix?
Find the fixed version or the vendor's mitigation. Check whether upgrading is a patch bump or a breaking change, and whether a configuration workaround exists in the meantime. Assign one owner and open one ticket with a time target.
Minute 55 to 60: tell people
Send a short message: what it is, whether you are affected, what you are doing, and when the next update comes. If you are not affected, say so with the evidence, since someone will ask.
What not to do on a small screen
Do not approve a production change from a phone without the context you would want at a desk. Triage and decide on the move, then execute with full tooling. Also avoid pasting secrets into any chat tool.
What to do
- Read the primary advisory and note affected versions.
- Query your inventory and record where the component runs.
- Check reachability and exposure for each affected service.
- Check the KEV catalog and the vendor's exploitation notes.
- Identify the fixed version or mitigation, with an owner and a time target.
- Send a short status message with the next update time.
- Make production changes from a full workstation with review.
Quick check
Can I triage a critical vulnerability from a phone?
You can do the research and the decision from any device. Production changes need the full context of a workstation and review.
What does Safeguard's mobile beta do?
It is listed as early access. We have not documented its specific features here. Check safeguard.sh/download or ask the Safeguard team.
Sources
Last reviewed: 18 October 2026.
