Report internet-facing vulnerabilities as their own group because exposure changes how quickly an attacker can reach them, so they deserve tighter targets and closer attention. A single blended number averages a few high exposure systems with many low exposure ones, and the average hides the risk.
There is precedent for the split
CISA's BOD 22-01 text refers to an earlier directive, BOD 19-02, which addresses remediation of critical and high vulnerabilities on internet-facing federal information systems. The point for everyone else is simple: public guidance already treats internet-facing systems as a distinct, higher priority class. You do not need to be a federal agency to use the same idea in your own policy.
What counts as internet-facing
Define it in writing. A reasonable definition is any asset that accepts connections from outside your trusted networks, including load balancers, APIs, web applications, VPN and remote access gateways, and anything exposed through a cloud security group. Include assets reachable through a vendor or partner link if that link crosses a trust boundary.
Decide how you will keep the list current. Asset discovery that runs continuously beats a spreadsheet that someone updates each quarter, since new exposures appear when teams ship.
How to build the split
- Maintain an inventory with an exposure attribute for each asset.
- Tag findings with the exposure of the asset they sit on.
- Report the metrics you already use, such as open count, age, and time to remediate, for each exposure group.
- Set a tighter remediation target for the internet-facing group.
- Review the exposure attribute at each release or infrastructure change.
| Group | Typical treatment |
|---|---|
| Internet-facing | Shortest targets, closest review |
| Internal, high value | Medium targets, owner review |
| Internal, low value | Longer targets, batched updates |
The exact windows are for your policy to set.
Things that go wrong
- Stale exposure data. An asset marked internal that was opened to the internet last month is a blind spot. Verify with external discovery.
- Shadow assets. Systems nobody registered do not appear in either group. Track how many assets you find that were not in the inventory.
- Indirect exposure. An internal service reachable through an exposed one is closer to the edge than it looks. Note attack paths when you can.
What to show executives
Two rows instead of one: internet-facing and everything else, each with count, oldest age, and known exploited items. A rule of thumb is that the first row should be small and clean. If it is not, say why and name the plan.
Where Safeguard fits
Safeguard can help with the inputs behind this. It runs SBOM and dependency scanning, reachability analysis to separate reachable findings from the rest, and policies and gates that you set. You can try a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how an exposed endpoint is listed with its findings, which is the kind of asset this split is about.
Quick check
Does behind a VPN count as internet-facing?
The VPN gateway itself does. Systems behind it are internal, but their risk depends on how strongly access is controlled.
Should internal findings be ignored?
No. They carry lower urgency but still matter, especially if an attacker gets inside through another route.
Sources
Last reviewed: 19 October 2026.
