Security teams should treat public exposure as a risk factor, not an automatic misconfiguration. Start by inventorying internet-facing workloads, validating why each one must be public, and pairing exposure with compensating controls such as patch management, segmentation, geo-based access restrictions, and runtime protection. The goal is to reduce attack surface without breaking legitimate business access to shared services.
How to reduce ransomware exposure without treating every public workload as unsafe
Public reachability is not the same thing as weak security. The useful question is whether a workload needs to be internet-facing, what it is allowed to do when exposed, and whether compensating controls shrink the blast radius enough to make that exposure acceptable. For many cloud services, the answer is to harden, segment, and monitor the asset rather than hide it.
That distinction matters because ransomware campaigns often begin with a public entry point, then try to turn one reachable system into broader access. Workloads that must remain public should be treated as high-value perimeter assets, with explicit ownership, tighter patching, and strong authentication and authorization around any administrative or integration path.
For service-to-service exposure, the security model should assume the network is reachable and push trust into workload identity, token scope, and transport protections. Guidance from the SPIFFE workload identity specification is relevant here because it shows how to bind workload identity to cryptographic attestation instead of relying on address-based trust. NHIMG’s Cloud Workload Identity Guide and NHI Authentication Guide are also useful for separating legitimate public access from unnecessary static secrets and long-lived credentials.
What controls actually make public exposure acceptable
Public exposure becomes manageable when it is paired with controls that reduce the attacker's options after initial contact. Patch management closes the easiest remote-execution paths. Segmentation prevents one compromised workload from becoming a pivot point. Geo-based restrictions and similar policy gates limit who can reach the service. Runtime protection adds detection and containment when prevention fails.
In practice, the control set should be matched to the workload's function. A customer-facing API needs different hardening than an admin console, batch integration endpoint, or file-transfer service. If the service must be reachable from anywhere, then the surrounding protections need to be stronger and more observable, not weaker because the business cannot tolerate downtime.
NHIMG’s Service Account Security Guide helps when the exposed workload depends on backend credentials, while the CI/CD Pipeline Identity Security Guide is relevant where build or deployment paths can become the real entry point into a public service. If an external control plane or identity layer is weak, public exposure becomes much riskier than the network diagram suggests.
How to decide whether a workload should stay public at all
Start with an inventory of every internet-facing workload, then ask whether the public dependency is truly required for the business function. Some services are public because they serve external users. Others are public only because no one has yet challenged the original design. Those are different cases, and they should not receive the same treatment.
Where a workload can be moved behind a broker, a private endpoint, an API gateway, or a restricted partner path, do that first. Where public access is unavoidable, document the reason, the owner, the allowed protocols, the exposed ports, and the compensating controls that make the risk acceptable. NHIMG’s Top 10 NHI Issues and Ultimate Guide to NHIs, Key Challenges and Risks are helpful reminders that sprawl, overprivilege, and poor visibility tend to turn exposed services into broader identity problems very quickly.
Risk and Threat Considerations
Publicly reachable cloud workloads are attractive to ransomware operators because they shorten the path from reconnaissance to impact. The risk is not just initial compromise, it is also lateral movement, credential harvesting, and the ability to encrypt or disrupt shared services once one workload is trusted too broadly.
Failure mechanism: The failure usually starts when teams assume that public access is inherently bad and either overexpose the service without compensating controls or lock it down so heavily that users create shadow access paths and reusable credentials.
Impact: The result is either preventable exposure or brittle security that pushes risk into weaker layers, increasing the odds of service disruption, privilege abuse, and ransomware propagation across connected workloads.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Service and Workgroup Devices) | Public workloads need strong service-to-service authentication. |
| AC-6 — Least Privilege | Compensating controls should limit what a compromised public workload can reach. | |
| SC-7 — Boundary Protection | The question centers on defending internet-facing systems at the trust boundary. | |
| Recommendation — Use IA-9 to authenticate exposed workloads with cryptographic trust instead of static network trust. Apply AC-6 to constrain exposed workloads to only the access they need. Use SC-7 to segment and filter traffic to public cloud workloads. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Public workloads depend on hardened configuration and patching. |
| CIS-12 — Network Infrastructure Management | Exposure decisions depend on controlling reachable services and network paths. | |
| CIS-5 — Account Management | Exposed services often fail through credential and service-account abuse. | |
| Recommendation — Use CIS-4 to harden and continuously maintain exposed workloads. Use CIS-12 to inventory and restrict internet-facing network paths. Use CIS-5 to govern service accounts and remove unnecessary access paths. | ||
| MITRE ATT&CK | T1190 — Exploit Public-Facing Application | Ransomware commonly starts from exposed cloud services. |
| T1021 — Remote Services | Restricting public access reduces attacker use of remote access paths. | |
| Recommendation — Map exposed workloads to T1190 and prioritize patching and hardening. Hunt for remote-service abuse and restrict exposed management interfaces. | ||
Practitioner Guidance
What to prioritise: Inventory every internet-facing workload first, then rank them by business criticality, exposed functionality, and the sensitivity of the credentials or downstream systems they can reach. A public endpoint with limited read-only access is not the same as a public administrative surface.
What to verify: For each exposed workload, confirm that there is a specific business reason for public reachability, a named owner, a defined patching cadence, and a documented compensating-control set. If you cannot explain why it must be public, treat it as a candidate for redesign.
Practitioner takeaway: The goal is not to eliminate public exposure everywhere, it is to make exposure deliberate, narrowly scoped, and resilient enough that ransomware cannot turn one reachable service into a broader compromise.
Related resources from NHI Mgmt Group
- How should security teams defend internet-facing Kubernetes workloads against exploit traffic built for other device types?
- How should security teams validate controls against ransomware crews that exploit internet-facing systems for initial access and persistence?
- How should security teams reduce ransomware risk when a public-facing application is exposed to the internet?
- How should security teams set up remote desktop access so it stays simple without exposing devices to the public internet?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
