SC-46 Cross domain policy enforcement

What SC-46 cross domain policy enforcement asks for and why it is hard

An overlay or contract has selected SC-46, or an architect has two security domains that must exchange data and needs to know what the control expects. The base control requires a policy enforcement mechanism, implemented either physically or logically, between the physical and network interfaces of connecting security domains. No SP 800-53B baseline includes SC-46, so it applies only when an organization selects it through tailoring or an overlay, which is why many teams first encounter it in a customer or agency requirement rather than in their own baseline selection. The risk is plain: data moves from one domain to another, and the domains may differ in sensitivity, classification, ownership or the rules that govern them. Without an enforcement point, a flow that should be blocked, filtered or inspected can pass through a path nobody reviewed. The control is hard because it is a design decision rather than a setting. Whether a guard, a data diode, a filtering proxy or a set of logically separated paths is the right mechanism depends on what each domain holds, which directions data may travel, and which content must be checked before it crosses. Those answers belong in the system architecture and the security plan, and an organization that cannot state them yet should resolve that before buying or configuring anything. Release 5.2.0 gives SC-46 one organization-defined parameter, so the organization must set its value and document the choice in its control implementation statement. The control relates to AC-4 (information flow enforcement) and SC-7 (boundary protection), so an assessor will expect the answers to those controls to be consistent with the cross domain design. Confirm the parameter wording and the related-control links against the current OSCAL catalog before you write the implementation statement, because the assessor will test against that release.

Which domain pairs and interfaces bring SC-46 into scope

SC-46 is not in any SP 800-53B baseline, so it applies only when your organization selects it through tailoring or an overlay. The scoping questions below decide whether a policy enforcement mechanism is needed at all and where it must sit, and each answer changes the design and the evidence an assessor will examine.

Which security domains actually connect

Start by listing every pair of security domains that exchange data, such as a corporate network and a restricted enclave, or a public-facing zone and an internal zone. SC-46 concerns the interfaces between connecting domains, so a pair with no data path needs no enforcement point. Record the owner, the classification of each side and the direction of flow. This inventory becomes the basis for the system design documentation an assessor will examine first.

Physical or network interface

The answer determines whether the mechanism is a hardware-separated device or a software policy point on a network path. A physical interface between domains calls for a dedicated enforcement component with a documented configuration, while a network interface can use firewall or proxy rules. Confirm which interface type each domain pair uses, because the control text allows either physical or logical implementation but the evidence differs.

Data classifications crossing the interface

Identify which classifications of information may pass in each direction. A one-way flow from a lower to a higher domain carries different risk than a bidirectional exchange, and content checks may be needed for data moving toward a less restricted side. Document the allowed flows as policy rules that the enforcement mechanism applies, and retain audit records of what was permitted or blocked so assessors can test the rules against actual traffic.

Shared services between domains

A shared identity provider, message broker, file transfer service or logging platform can create an indirect path between domains that the original design did not show. Map these services as part of each interface, because a shared component that carries data between domains may itself need to enforce policy. Confirm with the system owner whether a shared service is inside the boundary being assessed or outside it, since that decision sets who maintains the evidence.

Cloud tenancy and separate accounts

Separate cloud accounts, subscriptions or tenants often represent distinct security domains, and transit routing between them can cross an enforcement boundary without anyone naming it as an interface. Check whether peering, shared transit gateways or cross-account roles carry data between the accounts. The answer decides whether the enforcement point lives in your infrastructure code, in the provider's network controls or both, and the cloud provider's shared responsibility terms should be read against that answer.

Third-party links into a domain

A vendor integration, managed service or partner connection that terminates inside one of your domains forms an interface whose other side you do not control. Decide whether the third party sits in its own security domain and whether the agreed data exchange must pass a policy enforcement point. Record the decision with the connection's owner, because the scope of SC-46 changes with the contract, and the agreement should state who maintains the enforcement rules on each side.

How an assessor tests SC-46 against the SP 800-53A procedure

This table walks through the single determination statement for SC-46 in SP 800-53A Release 5.2.0, the examine, interview and test methods an assessor applies, and the findings that commonly come up. Read it as a preparation checklist: each row names what the assessor looks for and what your team should have ready before the assessment begins.

Assessment element	What the assessor checks	Common findings to prevent
Determination statement	Whether the organization has implemented a policy enforcement mechanism between the physical or network interfaces of connecting security domains, and whether that mechanism is physical or logical.	No enforcement point is identified at the interface between the domains, or the mechanism exists only as an informal practice.
Examine: system design documentation	Diagrams and narratives showing each security domain, each interface between domains, and where the enforcement mechanism sits in the data path.	Undocumented interfaces, or design diagrams that omit a bridge, shared service or file transfer path.
Examine: configuration settings and associated documentation	Rule sets, filtering and inspection policies on the enforcement point, and documentation explaining why each allowed flow is permitted.	Enforcement rules that allow more traffic, protocols or data types than the stated cross-domain policy permits.
Examine: system audit records	Logs showing permitted and denied transfers across the interface, with enough detail to reconstruct what was attempted.	Audit records that do not show denied transfers, or logs that are generated but never reviewed.
Interview: system and network administrators	How rules are changed, who approves them, and how the enforcement point is kept aligned with the documented policy.	Administrators describe a change process that is not reflected in the change records or configuration history.
Interview: policy and data owners	Which data may cross each domain boundary, the conditions for transfer, and who decides exceptions.	Owners cannot name the approved data types, or exceptions are granted outside the documented process.
Test: enforcement behavior	Whether the mechanism blocks transfers that the policy prohibits and passes those it allows, using controlled test traffic or transfers.	Test traffic reveals a bypass path, such as a second route between domains that does not pass the enforcement point.
Test: logging behavior	Whether a denied transfer produces an audit record that identifies the source, destination and reason.	Denials are enforced but leave no record, or records lack the detail needed to investigate.

How to implement SC-46 step by step, with the output of each step

This sequence takes an organization from an unclear picture of its connected security domains to a documented, tested and periodically reviewed cross domain policy enforcement mechanism that an assessor can trace from requirement to evidence. Each step ends with a named output that the next step depends on.

Identify domains and map their interfaces
Start by listing every security domain that the system connects to, such as a higher-classified enclave, a regulated data zone or an external partner network, and then record each physical and network interface where traffic or data crosses between them. The system owner and network team do this together, because the network team usually knows the links while the owner knows what each domain is trusted to hold. The step is complete when the interface inventory names each domain, each crossing point, the direction of flow and the data types that move across it. Assessors will ask to see this inventory first, since SC-46 applies to the interfaces between domains and cannot be scoped without it.
Write and approve the transfer policy
Next, draft a transfer policy that states which data may move between each pair of domains, under what conditions, and which checks the enforcement point must apply, such as content inspection, protocol restrictions or allowed source and destination pairs. The data owner, security lead and the owner of each connected domain should approve it, and the policy should name one accountable owner. The output is an approved transfer policy version with a record of who approved it and when. It is done when every interface in the inventory has a policy rule or an explicit decision that no transfer is allowed.
Select and place the enforcement mechanism
Choose how the policy will be enforced at each interface, whether by a hardware guard, a software guard, a stateful firewall or a web application filter, depending on the protocols and data involved. Open-source options exist for several layers. OPNsense, for example, is a stateful packet filter that passes, blocks or rejects traffic by source, destination, port and protocol, and Coraza is a web application firewall that can be used for HTTP inspection, though each must be confirmed against the protocols and assurance level the policy needs. The output is an architecture record showing where each mechanism sits, which interfaces it covers, and how traffic is forced through it, with no alternative path that bypasses it.
Configure rules and test with logging
Translate the approved transfer policy into rules on the enforcement mechanism, then test each rule with both permitted and prohibited traffic. Enable logging for each rule match so that allowed and blocked transfers can be reviewed later. Tests should confirm that prohibited transfers are actually stopped, that permitted ones pass and that the logs record both outcomes. The output is a set of test results, the rule configuration exported from the device and sample log records, all tied to the approved policy version. Assessors commonly examine system configuration settings and audit records for this control, so these artifacts should be kept under change control.
Set a review cycle tied to domain changes
Establish a recurring review of the transfer policy, the interface inventory and the rule set, and define triggers that force an earlier review, such as a new connected domain, a new data type, a firmware or software change to the enforcement point, or a finding from testing or logs. The review should compare current rules with the approved policy and the current architecture, record any drift, and assign corrective actions. The output is a dated review record with findings, decisions and updated versions of the inventory and policy where needed. This record closes the loop, because it shows that the enforcement remains aligned with the domains it protects over time.

Evidence that passes an SC-46 assessment and how to keep it current

An assessor testing SC-46 looks for proof that the enforcement mechanism exists, that it is configured to the approved transfer policy, and that it works in practice. The six artifacts below cover that chain, and each one goes stale unless it is tied to the change process that already governs the interfaces it describes.

System design documentation

This document shows each connected security domain, every physical or network interface between them, and the exact point where the policy enforcement mechanism sits. Assessors use it to confirm that no interface bypasses the enforcement point. Keep it current by requiring a design update in the same change ticket that adds or removes any interface, and by reviewing the diagram against live network topology at each assessment cycle. Confirm with your assessor whether they expect a logical, physical or combined view.

Enforcement rule configuration export

An export of the guard or firewall rules shows what the mechanism is actually instructed to pass, block or inspect between domains. For example, an OPNsense rule set exported with its aliases shows the permitted source, destination, port and protocol for each interface pair (illustrative). Store exports on a schedule and after every approved change, then diff them against the last approved baseline so that unexplained rule drift is caught before an assessor finds it.

Cross-domain transfer policy

The transfer policy states which data types may move between domains, in which direction, who may approve exceptions and what inspection applies to each flow. It must show an approval record, an owner, and both an approval date and a scheduled review date. Tie review to a fixed cycle and to any change in domain classification or data sensitivity, and confirm with your assessor how they expect the review interval to be set and evidenced.

Audit records of transfers

Logs of allowed and denied transfers show that the policy is enforced in operation, not only on paper. Confirm that each mechanism records the source, destination, interface, decision and time for every match, and that the records are retained and reviewed under your audit program. Test that logs reach a central store before relying on them, because an enforcement point that logs only locally is harder to evidence. Sample denied events and confirm each one has a documented disposition.

Enforcement test records

Test records show that transfers the policy forbids are actually blocked and that permitted transfers still pass. Run negative tests such as disallowed protocols, unlisted ports and unapproved data types from each side of every interface, and record the expected result, the observed result and the tester. Rerun the test set after each rule change or interface modification, and keep the results linked to the change record so the assessor can trace each test to a specific configuration.

Interface change records

Change records for interface modifications show who requested a new or altered cross-domain path, what security review it received, which rules changed and when the change was approved and implemented. Assessors often pick a recent change and trace it from request to rule export to test result, so each record should reference those artifacts. Make the change workflow the only route for editing enforcement rules, which keeps every other artifact in this set current without a separate review cycle.

What meeting SC-46 costs in money and effort

This table breaks SC-46 cost into components, showing who is paid, whether each cost is one-time or recurring, what pushes it up and how to keep it down. No price or duration is given because none has been supplied, so use the table to structure a written quote request and compare scopes.

Cost component	One-time or recurring	What drives it up	How to reduce it
Commercial guard or cross domain product licenses	Recurring (subscription or maintenance) plus one-time purchase where offered	Number of interfaces, classification levels and accreditation needs of the vendor product	Confirm whether the product is accredited for your domains; keep the enforcement point count low through a clear architecture
Open-source enforcement components	One-time build and recurring patching	Need for custom filtering rules, logging integration and hardening work	Open-source firewall and filtering tools such as OPNsense (BSD-2-Clause) can remove license spend, but you must confirm they meet your accreditation requirements
Engineering time to design and configure the enforcement point	One-time	Number of connected domains, protocols crossing the boundary and data flows needing inspection	Document the policy for each interface before build; reuse one rule pattern across interfaces where the data flows allow
Testing effort to show policy is enforced	One-time for initial tests, recurring for regression after changes	Number of allowed and denied flows to test, and whether bypass paths must be tested	Derive test cases directly from the policy table so each rule has one positive and one negative test
Evidence upkeep (configuration baselines, rule logs, change records)	Recurring	Frequency of rule changes, log volume and the number of reviewers involved	Use aliases and version-controlled configuration so rule sets are easier to review and compare over time
External review of the architecture	One-time, with periodic repeats after material change	Architectural complexity, novelty of the design and the independence the reviewer must show	Bring a written design and interface inventory to the review so the reviewer spends time on decisions rather than discovery
Auditor or assessor sampling time	Recurring at each assessment cycle	Number of enforcement points sampled, depth of rule-level testing and availability of evidence	Keep the SC-46 evidence package current (design documentation, configuration settings and audit records) so sampling does not reopen design questions
Management of tailoring decisions	One-time, revisited at each baseline or system change	Whether the organization must select SC-46 through tailoring or an overlay, which SP 800-53B baselines do not include	Record the selection rationale in the system security plan once, so the decision does not need to be re-argued at each assessment

Which open-source tools support SC-46 evidence, and their limits

SC-46 asks for an enforcement mechanism between connected security domains, and the evidence is the rule set and the record of what it allowed or blocked. The two tools below can generate parts of that evidence at a network or web interface, but neither is a cross domain guard, and each needs to be checked against your own domain requirements.

OPNsense as a packet filter

OPNsense is a stateful packet filter under the BSD-2-Clause license. Its rules pass, block or reject traffic by source, destination, port and protocol, and aliases let you group address ranges so one rule covers a whole domain. For SC-46, the exported rule set and aliases can document which interface pairs are permitted to talk and which are denied. Enable per-rule logging on the boundary rules so the live log view can show the matches an assessor will ask about. Confirm with your assessor that network-layer filtering alone satisfies the policy enforcement you need between your domains.

Per-rule logging for review

Each OPNsense rule can log its matches, which turns the firewall into a source of audit records for the interface between two domains. The evidence to retain is the rule configuration with its change history, plus log extracts that show denied traffic and the rule responsible. Decide how long those logs are kept and where they are forwarded, because a log that is only on the firewall can be lost in a failure. Ask whether your assessor expects the logs to be centralized and protected from modification.

Coraza as a web application firewall

Coraza is an Apache-2.0 web application firewall compatible with ModSecurity SecLang rulesets and the OWASP Core Rule Set. It is designed to detect attacks such as SQL injection, cross-site scripting and code injection in HTTP traffic. It integrates with Caddy, HAProxy, Traefik and Nginx, so it can sit in the request path of a web interface that crosses a domain boundary. It does not inspect arbitrary protocols or enforce data transfer policy between domains, so treat it as a control on application traffic only.

Rule sets and their version history

A Coraza deployment depends on the SecLang rules it loads, including the OWASP Core Rule Set, so the rule files and their versions are part of the evidence. Store the rule files in version control, record the audit log entries for blocked requests, and document which rules are disabled and why. An exception without a recorded reason is the kind of gap an assessor will flag. Confirm the rule set you choose meets the policy your domain owner has written.

Limits and what to confirm

Neither tool is presented here as a cross domain guard, a data diode or a certified product, and neither is a substitute for a mechanism that the organization has assessed against its own security domains. Both are open source, so your team owns configuration, patching and support unless you engage a partner or a vendor. Confirm the license terms, the supported versions, whether either product meets the requirements of your accreditation authority, and whether the design needs hardware-based enforcement that software alone cannot give.

Who owns each part of SC-46: your team, a partner and the auditor

Your organization owns SC-46. That means it owns the decision about which security domains are connected, what policy crosses between them, and who answers for the control when an assessor asks questions. SC-46 requires a policy enforcement mechanism between the interfaces of connecting security domains, and the requirement only makes sense once someone has defined those domains and the rules for moving information between them. Those decisions belong to the system owner and the information owners, not to a vendor.

Policy ownership: Maintain the written cross domain policy that states which flows are permitted, which are denied, and which require human review.
Domain decisions: Define each security domain, its classification, and the interfaces that connect it to others.
Accountable control owner: Name one person who answers for SC-46 in the System Security Plan and signs off on the assessment results.
Organization-defined parameter: Set the value SC-46 leaves to you, and record the reasoning in your tailoring decision.
Operational review: Review enforcement rules and audit records on a schedule you document, and approve changes before they reach production.

Confirm that your SC-46 owner has the authority to block an interface change, since that is the decision an assessor will ask about first.

Where SC-46 programs usually fall short and how to close each gap

SC-46 is simple to state and easy to under-implement because the enforcement point sits between domains that teams often manage separately. The gaps below recur in assessments, and each one comes down to whether the organization can show what crosses its domain boundaries, under which rule, and with what record.

No complete interface inventory

Many programs can name the main gateways between domains but not every physical or network interface that connects them, such as a shared storage mount, a replication link or a management network that reaches into a higher domain. SC-46 applies to the interfaces between connecting security domains, so an incomplete list means an untested path. Build the inventory from network diagrams, routing and firewall configuration, and asset records, then reconcile the two. Ask the assessor to see the list that the enforcement points are measured against.

Policy that exists only in a diagram

A diagram showing a guard between two domains does not show which transfers the guard allows, which it blocks, or who approved those rules. An assessor testing SC-46 looks for enforcement settings in the system configuration and the design documentation that explains them. Write the transfer policy as explicit rules per interface, export the configuration of each enforcement mechanism, and keep the two in step so the documentation describes what the device actually does.

Rule changes without a record

Guard and firewall rules often change during incidents, vendor onboarding or urgent business requests, and the change is rarely recorded against the approved policy. Over time the enforced behavior drifts from the documented intent, which an assessor will find when comparing configuration to design documentation. Route every rule change through a ticket that states the business reason, the approver and the expiry for temporary exceptions, and export the configuration on a schedule so changes can be compared over time.

Audit logs that miss denied transfers

Teams usually confirm that allowed transfers are logged, but SC-46 evidence depends on showing that the policy was enforced, which includes the transfers it stopped. If denied events are not recorded or are discarded by a default retention setting, the organization cannot demonstrate enforcement or investigate attempted crossings. Confirm that the mechanism logs both permitted and denied events with timestamps and interface identifiers, then send those records to the central audit store that the organization already reviews.

No review when domains change

A new system, a reclassification of data or a change in network ownership can create a new domain or move an interface into a different security domain without anyone revisiting the enforcement point. The gap shows up when a domain is added and the existing guard still reflects the old design. Add a checkpoint to the change and onboarding process that asks whether the new or reclassified domain changes any interface, and require the enforcement policy and interface inventory to be updated before the change closes.

Questions buyers ask about SC-46 cost, effort and outside help

Does SC-46 apply to my system without a tailored overlay?

No. SP 800-53B does not assign SC-46 to any security or privacy baseline, so a system at low, moderate or high impact does not need it unless the organization selects it through tailoring or an overlay. Appendix C of SP 800-53 Rev. 5 lists it as implemented by the system. The reasons to select it usually come from a contract, a regulator or a documented architecture decision, such as a boundary between domains of different sensitivity. Confirm with the authorizing official or contracting body whether it is required before planning any work. FedRAMP's Rev5 baselines also do not require it at Class B, C or D.

How much effort does SC-46 take, and what drives it?

Effort depends on how many interfaces connect security domains and how each one is enforced. The control has one organization-defined parameter and no enhancements, so the written requirement is short, but the engineering work is not. The main drivers are:

The number of physical and network interfaces between domains
Whether enforcement is hardware, software or a mix of both
How many rule sets must be designed, tested and reviewed
How much existing audit logging can already show enforcement decisions

No supplied fact gives a duration or fee for this work, so ask the implementation partner to break the effort down by interface in the written scope.

Can an in-house team implement SC-46 without outside help?

Often yes, if the team already runs boundary protection and has staff who can design and test cross-domain rules. SC-46 overlaps with AC-4 and SC-7, so the people who manage those controls are usually the right owners. An in-house team needs enough time to build the interface inventory, document the policy and collect evidence during the assessment. Outside help is most useful when the team lacks experience with guard products, needs an independent review of the design, or must meet a deadline set by a customer or regulator. Either way, the organization still owns the control.

What does the organization need to provide for SC-46 work?

The organization must supply the people and records that describe its domains. Expect to provide:

Named domain owners who can approve the policy for each side of an interface
A current inventory of physical and network interfaces between domains
Architecture and data flow diagrams that show what crosses each boundary
Change records for past rule and configuration updates
Access to audit records that show enforcement decisions

Without these inputs, the assessment evidence will be weak, so confirm early who will provide each item.

How long does SC-46 implementation take?

The timeline depends on scope, mainly the number of domain interfaces, the enforcement technology chosen and how many approvals each rule change needs. No researched figure gives a standard duration, so treat any single number as unverified. A small, well-documented boundary with existing firewall logging can move faster than a multi-domain design that needs new hardware. Ask for a phased plan in the written scope, with milestones for interface inventory, design approval, deployment, testing and evidence collection.

Can DeployOpen issue the SC-46 assessment or certification?

No. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. An independent assessor or certification body must test the control and issue any formal result. The assessment procedure for SC-46 in SP 800-53A Rev. 5 uses examine, interview and test methods, and the assessor will look at system design documentation, configuration settings and audit records. DeployOpen can help assemble those materials so the assessor can review them efficiently.

What should a written scope for SC-46 work include?

A written scope should name every interface in scope, the enforcement mechanism for each, the owner of each domain, and the deliverables. Ask the implementation partner to state:

The interfaces covered and those excluded, with reasons
The enforcement design, including whether it is hardware or software, and the tools used
The policy and rule documentation to be delivered
The evidence set mapped to the examine objects in SP 800-53A
Responsibilities for each party, including who approves changes
Timelines, milestones and the assumptions behind them
Any ongoing support, which is available as a retainer

Fixed-scope engagements agree these items in writing before work starts, so ask for them in the quote.

How DeployOpen works on this

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, including the enforcement points between connected security domains where SC-46 applies. We prepare the systems and evidence an assessor will examine, while your organization owns the control decision and an independent assessor forms the conclusion.

How we scope

Confirm with your organization whether SC-46 is selected through tailoring or an overlay, since no SP 800-53B baseline includes it.
Identify every pair of connected security domains and the physical or network interfaces where a policy enforcement mechanism must sit.
Agree in writing which enforcement components, rule sets and evidence sources are in scope before work starts, since engagements are fixed-scope.

How we build

Document the domain interfaces, data flow directions and the policy each enforcement point applies, so the design can be examined.
Deploy and configure self-hosted enforcement components in your environment, with rule sets kept under version control.
Test that blocked traffic and disallowed cross-domain flows are actually stopped, and record the results for review.

How we hand over

Deliver system design documentation, configuration settings with their explanation, and sample audit records for the assessor to examine.
Provide a test record showing how each enforcement point was exercised, with the results and any open findings listed.
Hand over runbooks so your staff can operate, change and re-test the enforcement points after the engagement ends.

How we support

Offer ongoing support, upgrades and continuous testing of enforcement points as a retainer, if your organization wants it.
Re-check evidence after significant changes to domain interfaces, rule sets or the enforcement platform.
Work with your chosen independent assessor during the assessment, answering questions about the systems we built and configured.