consider* putting endpoints on a private overlay network in which network access is cryptography-gated (e.g. x.509 cert based).
then, a misconfigured endpoint (or a zero day etc.) can't be exploited by any_actor_on_the_internet - actors need to first complete the provisioning process you choose to enforce to be authorized to use the private overlay.
*not one size fits all, e.g. bad option if endpoints need to accept requests from unknowns.
however, many endpoints only need to accept requests from known (identified, authenticated, authorized) endpoints, and the added friction to id/authN/authZ get use the private overlay is not a business impediment.
there is a stigma here due to the horrors of NAC on private enterprise WANs. but NAC goals can be accomplished without that baggage via internet overlays and modern cryptography.
to be clear, i am by no means advocating to abandon traditional methods of endpoint auth - this it is just another layer which recognizes that single layers are rarely airtight (e.g. what just happened to Authy and Twilio).
then, a misconfigured endpoint (or a zero day etc.) can't be exploited by any_actor_on_the_internet - actors need to first complete the provisioning process you choose to enforce to be authorized to use the private overlay.
*not one size fits all, e.g. bad option if endpoints need to accept requests from unknowns.
however, many endpoints only need to accept requests from known (identified, authenticated, authorized) endpoints, and the added friction to id/authN/authZ get use the private overlay is not a business impediment.
there is a stigma here due to the horrors of NAC on private enterprise WANs. but NAC goals can be accomplished without that baggage via internet overlays and modern cryptography.
to be clear, i am by no means advocating to abandon traditional methods of endpoint auth - this it is just another layer which recognizes that single layers are rarely airtight (e.g. what just happened to Authy and Twilio).