{ "api_version": "1", "kind": "dse_post", "self": "https://update.dsesecurity.com/api/v1/posts/physical-access-control-ot-segmentation-remote-access/", "item": { "id": "https://update.dsesecurity.com/updates/physical-access-control-ot-segmentation-remote-access/", "slug": "physical-access-control-ot-segmentation-remote-access", "url": "https://update.dsesecurity.com/updates/physical-access-control-ot-segmentation-remote-access/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/physical-access-control-ot-segmentation-remote-access.md", "json": "https://update.dsesecurity.com/api/v1/posts/physical-access-control-ot-segmentation-remote-access/" }, "title": "Treat physical access control as OT: segment it, constrain remote access, preserve availability", "summary": "NIST explicitly includes physical access-control systems in OT and frames their security around mapped data flows, segmentation, controlled remote access, and availability.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "advisory", "name": "Advisory" }, "featured": false, "topics": [ { "slug": "access-control", "name": "Access Control", "url": "https://update.dsesecurity.com/topic/access-control/" }, { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-07-19T21:29:04+00:00", "modified_at": "2026-07-19T21:29:04+00:00", "reviewed_on": "2026-07-19", "reading_minutes": 2, "word_count": 438, "potentially_affected": "Networked physical access-control servers, controllers, readers, management workstations, building-system integrations, cloud connections, and temporary or persistent vendor access.", "dse_recommendation": "Map access-system dependencies and required flows, build risk-based zones, limit remote access, and test security changes against door availability and emergency operations.", "primary_source": { "name": "NIST SP 800-82 Rev. 3 — Guide to Operational Technology Security", "url": "https://csrc.nist.gov/pubs/sp/800/82/r3/final", "published_on": "2023-09-28", "authority": "National Institute of Standards and Technology" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

Physical access control is within NIST’s OT scope

\n

Source fact: NIST SP 800-82 Rev. 3 defines operational technology broadly and explicitly lists physical access-control systems as an example. Its PACS description includes credentials, readers or keypads, door controllers, an access-control server, rules and privileges, and audit logs. The server can be on premises or managed in the cloud.

\n

The OT framing changes how controls are introduced. NIST explains that rebooting may be unacceptable where availability is required, outages may need to be planned well in advance, redundancy can be necessary, and high-availability designs need extensive predeployment testing. A security improvement that unexpectedly prevents authorized entry or emergency work is not a successful deployment.

\n\n

Segment from documented flows

\n

NIST recommends segmentation or zoning by factors such as function, criticality, trust, location, management authority, or data flow. Segmentation can use physically separate infrastructure or logical VLANs. Mapped data flows should identify required communications, while firewalls, gateways, switches, routers, or other enforcement devices allow only explicitly authorized traffic between segments. A DMZ can serve as a boundary where appropriate.

\n

Remote access should be provided only when justified and limited to the business need. It should not bypass safety or security controls. NIST says multi-factor authentication should be considered and that temporary vendor-maintenance access still needs secure procedures. Remote-access disablement is important, but its operation must not disrupt the OT process.

\n\n

Current-publication boundary

\n

Rev. 3, finalized September 28, 2023, remains NIST’s current final SP 800-82 publication as of this review. NIST has begun a Rev. 4 pre-draft process, but a pre-draft is not final guidance. SP 800-82 is also architecture-level material, not a configuration manual for a particular access-control platform.

\n\n

DSE architecture checklist

\n

DSE recommendation: This is DSE operational synthesis and must be reconciled with product, facility, egress, and emergency requirements.

\n
    \n
  1. Inventory readers, controllers, servers, workstations, directories, databases, switches, cloud services, and vendor paths.
    2. \n
  2. Assign owners and criticality, including the consequence of each component or dependency being unavailable.
    3. \n
  3. Document normal, emergency, offline, update, backup, monitoring, and support data flows.
    4. \n
  4. Create zones and enforcement rules from those flows; do not rely on a VLAN name as proof of isolation.
    5. \n
  5. Remove unjustified remote paths and make required sessions named, approved, limited, monitored, and time-bound.
    6. \n
  6. Use strong authentication and encryption where supported, with compensating controls documented for legacy limitations.
    7. \n
  7. Test controller autonomy, door operation, alarms, audit, emergency workflows, remote-access disablement, and recovery.
    8. \n
  8. Review the architecture after integration, cloud, identity, site, or vendor-support changes.
    9. \n
\n\n

Official references

\n", "content_text": "Physical access control is within NIST’s OT scope\nSource fact: NIST SP 800-82 Rev. 3 defines operational technology broadly and explicitly lists physical access-control systems as an example. Its PACS description includes credentials, readers or keypads, door controllers, an access-control server, rules and privileges, and audit logs. The server can be on premises or managed in the cloud.\nThe OT framing changes how controls are introduced. NIST explains that rebooting may be unacceptable where availability is required, outages may need to be planned well in advance, redundancy can be necessary, and high-availability designs need extensive predeployment testing. A security improvement that unexpectedly prevents authorized entry or emergency work is not a successful deployment.\n\nSegment from documented flows\nNIST recommends segmentation or zoning by factors such as function, criticality, trust, location, management authority, or data flow. Segmentation can use physically separate infrastructure or logical VLANs. Mapped data flows should identify required communications, while firewalls, gateways, switches, routers, or other enforcement devices allow only explicitly authorized traffic between segments. A DMZ can serve as a boundary where appropriate.\nRemote access should be provided only when justified and limited to the business need. It should not bypass safety or security controls. NIST says multi-factor authentication should be considered and that temporary vendor-maintenance access still needs secure procedures. Remote-access disablement is important, but its operation must not disrupt the OT process.\n\nCurrent-publication boundary\nRev. 3, finalized September 28, 2023, remains NIST’s current final SP 800-82 publication as of this review. NIST has begun a Rev. 4 pre-draft process, but a pre-draft is not final guidance. SP 800-82 is also architecture-level material, not a configuration manual for a particular access-control platform.\n\nDSE architecture checklist\nDSE recommendation: This is DSE operational synthesis and must be reconciled with product, facility, egress, and emergency requirements.\n\nInventory readers, controllers, servers, workstations, directories, databases, switches, cloud services, and vendor paths.\nAssign owners and criticality, including the consequence of each component or dependency being unavailable.\nDocument normal, emergency, offline, update, backup, monitoring, and support data flows.\nCreate zones and enforcement rules from those flows; do not rely on a VLAN name as proof of isolation.\nRemove unjustified remote paths and make required sessions named, approved, limited, monitored, and time-bound.\nUse strong authentication and encryption where supported, with compensating controls documented for legacy limitations.\nTest controller autonomy, door operation, alarms, audit, emergency workflows, remote-access disablement, and recovery.\nReview the architecture after integration, cloud, identity, site, or vendor-support changes.\n\nOfficial references\n\nNIST SP 800-82 Rev. 3 — the current final OT scope and security guidance.\nGuide to Operational Technology Security — PACS architecture, availability, segmentation, and remote-access details.\nNIST Operational Technology Security publications — current final and draft status tracking.", "content_markdown": "## Physical access control is within NIST’s OT scope\n\nSource fact: NIST SP 800-82 Rev. 3 defines operational technology broadly and explicitly lists physical access-control systems as an example. Its PACS description includes credentials, readers or keypads, door controllers, an access-control server, rules and privileges, and audit logs. The server can be on premises or managed in the cloud.\n\nThe OT framing changes how controls are introduced. NIST explains that rebooting may be unacceptable where availability is required, outages may need to be planned well in advance, redundancy can be necessary, and high-availability designs need extensive predeployment testing. A security improvement that unexpectedly prevents authorized entry or emergency work is not a successful deployment.\n\n## Segment from documented flows\n\nNIST recommends segmentation or zoning by factors such as function, criticality, trust, location, management authority, or data flow. Segmentation can use physically separate infrastructure or logical VLANs. Mapped data flows should identify required communications, while firewalls, gateways, switches, routers, or other enforcement devices allow only explicitly authorized traffic between segments. A DMZ can serve as a boundary where appropriate.\n\nRemote access should be provided only when justified and limited to the business need. It should not bypass safety or security controls. NIST says multi-factor authentication should be considered and that temporary vendor-maintenance access still needs secure procedures. Remote-access disablement is important, but its operation must not disrupt the OT process.\n\n## Current-publication boundary\n\nRev. 3, finalized September 28, 2023, remains NIST’s current final SP 800-82 publication as of this review. NIST has begun a Rev. 4 pre-draft process, but a pre-draft is not final guidance. SP 800-82 is also architecture-level material, not a configuration manual for a particular access-control platform.\n\n## DSE architecture checklist\n\nDSE recommendation: This is DSE operational synthesis and must be reconciled with product, facility, egress, and emergency requirements.\n\n- Inventory readers, controllers, servers, workstations, directories, databases, switches, cloud services, and vendor paths.\n\n- Assign owners and criticality, including the consequence of each component or dependency being unavailable.\n\n- Document normal, emergency, offline, update, backup, monitoring, and support data flows.\n\n- Create zones and enforcement rules from those flows; do not rely on a VLAN name as proof of isolation.\n\n- Remove unjustified remote paths and make required sessions named, approved, limited, monitored, and time-bound.\n\n- Use strong authentication and encryption where supported, with compensating controls documented for legacy limitations.\n\n- Test controller autonomy, door operation, alarms, audit, emergency workflows, remote-access disablement, and recovery.\n\n- Review the architecture after integration, cloud, identity, site, or vendor-support changes.\n\n## Official references\n\n- [NIST SP 800-82 Rev. 3](https://csrc.nist.gov/pubs/sp/800/82/r3/final) — the current final OT scope and security guidance.\n\n- [Guide to Operational Technology Security](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-82r3.pdf) — PACS architecture, availability, segmentation, and remote-access details.\n\n- [NIST Operational Technology Security publications](https://csrc.nist.gov/projects/operational-technology-security/publications) — current final and draft status tracking." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo.png" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/physical-access-control-ot-segmentation-remote-access/", "url": "https://update.dsesecurity.com/updates/physical-access-control-ot-segmentation-remote-access/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-07-19" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/physical-access-control-ot-segmentation-remote-access/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Treat physical access control as OT: segment it, constrain remote access, preserve availability", "item": "https://update.dsesecurity.com/updates/physical-access-control-ot-segmentation-remote-access/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/physical-access-control-ot-segmentation-remote-access/#article", "identifier": "https://update.dsesecurity.com/updates/physical-access-control-ot-segmentation-remote-access/", "url": "https://update.dsesecurity.com/updates/physical-access-control-ot-segmentation-remote-access/", "headline": "Treat physical access control as OT: segment it, constrain remote access, preserve availability", "description": "NIST explicitly includes physical access-control systems in OT and frames their security around mapped data flows, segmentation, controlled remote…", "abstract": "NIST explicitly includes physical access-control systems in OT and frames their security around mapped data flows, segmentation, controlled remote access, and availability.", "articleBody": "Physical access control is within NIST’s OT scope\nSource fact: NIST SP 800-82 Rev. 3 defines operational technology broadly and explicitly lists physical access-control systems as an example. Its PACS description includes credentials, readers or keypads, door controllers, an access-control server, rules and privileges, and audit logs. The server can be on premises or managed in the cloud.\nThe OT framing changes how controls are introduced. NIST explains that rebooting may be unacceptable where availability is required, outages may need to be planned well in advance, redundancy can be necessary, and high-availability designs need extensive predeployment testing. A security improvement that unexpectedly prevents authorized entry or emergency work is not a successful deployment.\n\nSegment from documented flows\nNIST recommends segmentation or zoning by factors such as function, criticality, trust, location, management authority, or data flow. Segmentation can use physically separate infrastructure or logical VLANs. Mapped data flows should identify required communications, while firewalls, gateways, switches, routers, or other enforcement devices allow only explicitly authorized traffic between segments. A DMZ can serve as a boundary where appropriate.\nRemote access should be provided only when justified and limited to the business need. It should not bypass safety or security controls. NIST says multi-factor authentication should be considered and that temporary vendor-maintenance access still needs secure procedures. Remote-access disablement is important, but its operation must not disrupt the OT process.\n\nCurrent-publication boundary\nRev. 3, finalized September 28, 2023, remains NIST’s current final SP 800-82 publication as of this review. NIST has begun a Rev. 4 pre-draft process, but a pre-draft is not final guidance. SP 800-82 is also architecture-level material, not a configuration manual for a particular access-control platform.\n\nDSE architecture checklist\nDSE recommendation: This is DSE operational synthesis and must be reconciled with product, facility, egress, and emergency requirements.\n\nInventory readers, controllers, servers, workstations, directories, databases, switches, cloud services, and vendor paths.\nAssign owners and criticality, including the consequence of each component or dependency being unavailable.\nDocument normal, emergency, offline, update, backup, monitoring, and support data flows.\nCreate zones and enforcement rules from those flows; do not rely on a VLAN name as proof of isolation.\nRemove unjustified remote paths and make required sessions named, approved, limited, monitored, and time-bound.\nUse strong authentication and encryption where supported, with compensating controls documented for legacy limitations.\nTest controller autonomy, door operation, alarms, audit, emergency workflows, remote-access disablement, and recovery.\nReview the architecture after integration, cloud, identity, site, or vendor-support changes.\n\nOfficial references\n\nNIST SP 800-82 Rev. 3 — the current final OT scope and security guidance.\nGuide to Operational Technology Security — PACS architecture, availability, segmentation, and remote-access details.\nNIST Operational Technology Security publications — current final and draft status tracking.", "datePublished": "2026-07-19T21:29:04+00:00", "dateModified": "2026-07-19T21:29:04+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/physical-access-control-ot-segmentation-remote-access/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@id": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": "https://update.dsesecurity.com/assets/dse-updates-share.png", "articleSection": [ "Access Control", "Business Continuity", "Cybersecurity", "Networks & Infrastructure" ], "keywords": [ "Access Control", "Business Continuity", "Cybersecurity", "Networks & Infrastructure", "Guide", "Advisory priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Access Control", "url": "https://update.dsesecurity.com/topic/access-control/" }, { "@type": "Thing", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "@type": "Thing", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "Thing", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "wordCount": 438, "timeRequired": "PT2M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "NIST SP 800-82 Rev. 3 — Guide to Operational Technology Security", "url": "https://csrc.nist.gov/pubs/sp/800/82/r3/final", "datePublished": "2023-09-28" } } ] } }