PR.IR-01 says networks and environments are protected from unauthorized logical access and usage. In practice it asks you to decide which systems may talk to which, block everything else, and be able to prove the rules exist and are reviewed. It applies to office networks, cloud accounts, VPCs, SaaS tenants, and developer environments alike.
CSF is voluntary guidance. There is no CSF certification, so nobody can be "NIST compliant". You use the outcome to describe where you are and where you are heading.
What good looks like
Your environments are split by trust. Production, staging, corporate IT, guest wifi, and any IoT or lab gear sit in separate segments. Traffic between segments is allowed only where a named business need exists. Traffic from the internet reaches only the services meant to be public.
NIST's own implementation examples point the same way: segment networks and cloud platforms by trust boundary and platform type, permit only necessary communication from external networks, and move toward zero trust designs where location alone never grants access.
How to implement it
- List your environments and mark which are production, which hold customer data, and which are internet facing.
- Put each in its own network or cloud account. In AWS, Azure, or GCP that usually means separate accounts or projects plus separate VPCs.
- Set default deny on security groups and firewall rules. Open ports one at a time with a written reason.
- Replace flat VPN access with per application access that checks identity and device state.
- Remove default routes between staging and production. Developers should not reach production databases from laptops without a logged, approved path.
- Review rules every quarter. Delete rules nobody can explain.
A worked example
Picture a 60 person software company with one production cloud account, one staging account, and an office network. Today a developer laptop on the office wifi can reach the staging database directly, and staging holds a copy of last month's production data. A contractor connects through a shared VPN login.
The fix is not exotic. Move staging data to synthetic or masked records. Give the staging and production accounts separate networks with no peering. Put the contractor on a per person identity with access to one application, and set the VPN so it reaches that application only. Change the guest wifi so it cannot see the office printer subnet. Each step is a rule change, and each one leaves a ticket you can show later.
Why segmentation matters more than a perimeter
Most attacks that cause real damage start with one ordinary foothold, such as a phished laptop or a leaked token. What decides the size of the incident is where that foothold can go next. Segmentation shrinks the answer. When a compromised device can reach only its own segment, the incident is a bad afternoon. When it can reach everything, it is a breach.
Zero trust language adds a second idea: do not treat the network location as proof of anything. Each request to an application is checked for who is asking, from what device, and whether they are allowed. You do not need a product to start. Requiring single sign on with strong authentication for internal apps, and removing the assumption that the office network is safe, already moves you in that direction.
Review habits that keep it true
Segmentation decays. Rules get added during outages and stay forever. Put a recurring calendar entry for a rule review, export the rules before and after, and keep the diff. Look specifically for rules that allow any source, any port, or a very wide address range. Ask the owner of each to justify it or let it go.
A maturity path you can follow
Stage one is visibility. Draw what exists, even roughly, and list every path from the internet and from the office into production. Many teams find paths nobody remembers creating, such as an old test VPN or a database with a public address.
Stage two is default deny. Change firewall and security group rules so that nothing is allowed unless listed, then add the rules your services need. Do this one environment at a time, starting with production. Keep a rollback plan for each change window.
Stage three is identity aware access. Replace network based trust with checks on who and what is connecting. Administrative access to production goes through a bastion or access broker that records sessions, requires multi factor authentication, and issues short lived credentials.
Stage four is continuous checking. Run a scheduled job that exports rules, flags anything open to the whole internet, and compares against the last approved state. Feed exceptions into the same ticket queue as other security work.
Questions customers ask
Security questionnaires often ask whether production is separated from development, whether administrative access uses multi factor authentication, and how network rules are reviewed. If you can answer each with a diagram, an export, and a review date, you will clear most of them quickly.
Evidence to collect
- A network or environment diagram showing segments and trust boundaries.
- Exported firewall and security group rules with a review date.
- A ticket or change record for each rule added in the last year.
- Screenshots or config exports showing default deny.
- The last access path review for production.
Common gaps
Flat networks where every office device reaches every server. Security groups open to the whole internet on SSH or database ports. Staging that shares credentials or network paths with production. Rules added in an incident and never removed. A diagram that was accurate two years ago.
Quick check
Does a firewall at the office edge satisfy this outcome by itself?
No. The outcome covers networks and environments, including cloud accounts and SaaS. An edge firewall says nothing about segmentation inside your cloud or access between environments.
Does a VPN count as segmentation?
A VPN controls how people get in. Segmentation controls where they and their devices can go once inside. You usually need both.
Sources
- NIST Cybersecurity Framework 2.0 (NIST CSWP 29), PR.IR-01 and its implementation examples.
