ITAR Foreign Person Rules: The Risk Most Companies Don't Manage Well

I've watched a lot of ITAR violations cross my desk over the years. The majority weren't about shipping controlled hardware to embargoed countries or selling weapons systems to hostile actors. They were about foreign nationals gaining access to technical data, often inadvertently, often through systems the company thought were properly controlled. The pattern is consistent: companies that handle ITAR-controlled technical data tend to understand the export licensing requirements for physical items but completely underestimate the risk of electronic access by foreign persons.

The ITAR foreign person rules exist because U.S. defense technology protection isn't just about what crosses borders physically—it's about who has access to technical data, regardless of where that access occurs. When a foreign national views, downloads, or receives controlled technical data, that's considered an export under ITAR, even if the data never leaves U.S. soil. This concept, called a "deemed export," is where most companies struggle.

What makes this particularly challenging in 2026 is that our technology infrastructure has evolved faster than most compliance programs. Cloud services, remote work, distributed teams, and third-party integrations have all created new pathways for foreign person access that didn't exist when many companies first built their ITAR compliance frameworks. The rules haven't changed—companies are still required to prevent unauthorized access to defense articles and technical data—but the attack surface has expanded dramatically.

Why Foreign Person Access Is the Highest-Risk Area

The State Department's enforcement history tells the story clearly. When you review ITAR consent agreements and administrative enforcement cases, unauthorized disclosure to foreign persons appears repeatedly. These aren't corner cases—they're the most common substantive violation pattern outside of registration and reporting failures.

The reason is straightforward: physical exports require deliberate action. Someone has to prepare a shipment, complete customs documentation, arrange transport. There are multiple checkpoints where someone might catch an error. Foreign person access, by contrast, can happen through a single misconfigured permission setting, a forwarded email, or a remote desktop session. The margin for error is razor-thin.

I've seen companies with sophisticated physical export controls—properly licensed shipments, detailed shipping logs, customs compliance procedures—completely miss the fact that their engineering file server was accessible to an H-1B employee whose country of citizenship wasn't on an approved list. They had controls, just not in the right places.

The other factor is visibility. Physical exports create records: bills of lading, export licenses, customs declarations. Electronic access often leaves minimal audit trail unless you've specifically designed systems to create one. Many companies discover violations only during internal audits or government reviews, months or years after the access occurred.

The Cloud Amplification Effect

Cloud infrastructure has fundamentally changed the risk profile for ITAR foreign person compliance. When technical data lived on on-premises servers with network perimeter controls and physical security, access control was simpler (though never simple). Cloud environments introduce layers of complexity that most companies haven't fully addressed.

Your data might be stored in U.S.-based AWS regions, but who has administrative access to that environment? AWS support personnel could include foreign nationals. Does your configuration prevent their access to ITAR-controlled data? Are you using services where the vendor's standard support model includes access you can't adequately restrict?

The same applies to SaaS platforms. Your CAD software, PLM system, or collaboration platform might be hosted by a vendor whose support and engineering teams are distributed globally. Unless you've specifically configured the environment to prevent foreign person access and verified the vendor's ability to enforce those restrictions, you're running exposure. For more on how these cloud challenges manifest in defense contractor environments, see ITAR and the Cloud: What Defense Contractors Need to Know in 2026.

What "Foreign Person" Actually Means Under ITAR

The definition matters because companies regularly get it wrong. Under ITAR § 120.16, a "foreign person" means any person who is not a U.S. person. A U.S. person, in turn, is defined as a U.S. citizen, lawful permanent resident (green card holder), protected individual under 8 U.S.C. 1324b(a)(3) (asylees and refugees), or a U.S. entity organized under U.S. law where no foreign control or influence exists.

The critical point: work authorization status is not the same as ITAR status. An H-1B visa holder is authorized to work in the United States but remains a foreign person for ITAR purposes unless they're also a lawful permanent resident. The same applies to other visa categories: L-1, TN, E-3, and so on. I've encountered multiple companies that assumed anyone legally employed was automatically cleared for ITAR access. That's not how the regulation works.

The verification burden falls on the company. You need to confirm each person's status before granting access to controlled technical data. This means collecting documentation (I-9 forms capture some of this, but not all) and maintaining records that demonstrate you verified status before access was granted. In my experience, smaller defense contractors often lack formal processes here—they rely on HR systems that weren't designed to track ITAR person status separately from employment eligibility.

The Citizenship Question

Companies sometimes hesitate to ask about citizenship, worried about discrimination claims. The concern is understandable but misplaced in this context. ITAR regulations specifically require you to determine whether individuals are U.S. persons before granting access to controlled data. This is a legal compliance requirement, not discretionary screening.

The key is to apply the requirement consistently and document that access decisions are driven by the nature of the technical data and the individual's ITAR status, not by national origin discrimination. You're not making hiring decisions based on citizenship—you're making access control decisions based on regulatory requirements. Those are distinct legal frameworks, and the distinction matters.

Where Foreign Person Access Happens Without You Realizing It

The violations I've seen weren't the result of malicious intent. They happened because companies didn't map out all the pathways through which foreign persons could access technical data. Here are the patterns that show up repeatedly.

Remote Access and VPN Configuration

Remote work has become standard, but many VPN configurations don't differentiate between access to general corporate resources and access to ITAR-controlled technical data. If your VPN allows authenticated users to reach engineering file shares, CAD libraries, or technical documentation repositories without additional access controls, you need to know the ITAR status of everyone with VPN credentials.

I've reviewed environments where the VPN was role-based (engineering, finance, operations) but not person-status-based. A foreign national engineer had the same VPN profile as a U.S. person engineer, giving access to the same file systems. The company assumed that physical office access controls were sufficient, not accounting for the fact that remote access bypassed those controls entirely.

Email and Collaboration Platforms

Email is one of the most common vectors for unauthorized disclosure. An engineer forwards a technical drawing to a colleague without checking whether that colleague is a U.S. person. A project team uses a Slack channel or Microsoft Teams workspace that includes foreign nationals, and someone drops a controlled document into the shared files.

Technical controls can help here—data loss prevention (DLP) rules, email filtering, Rights Management Services (RMS)—but they're only effective if you've clearly tagged what data is ITAR-controlled and configured the tools to enforce restrictions. Most companies have some of these tools deployed but haven't tuned them specifically for ITAR foreign person access.

Third-Party Vendor Access

You contract with a software vendor for CAD support, a consulting firm for systems engineering, or a logistics provider for supply chain management. Do those vendors employ foreign nationals? Do their support agreements include remote access to your systems or data? If so, you need to control what they can access and verify the person status of anyone who will touch ITAR-controlled technical data.

Vendor contracts often include broad access rights for troubleshooting and support. Unless you've negotiated restrictions and verified compliance, you're relying on the vendor to manage foreign person access according to your regulatory requirements. That's not a position you want to be in during an audit.

Cloud Service Administrative Access

Cloud platforms typically include support tiers where provider personnel can access your environment to resolve technical issues. AWS, Azure, Google Cloud, and other providers have implemented controls to restrict support personnel access based on customer requirements, but those controls aren't enabled by default—you have to configure them.

If you're storing ITAR-controlled technical data in cloud infrastructure, you need to ensure that foreign persons within the cloud provider's organization cannot access that data. This usually means specific service configurations, encryption with customer-managed keys, and contractual commitments from the provider. It's technical, it's contractual, and it's a compliance requirement that many companies overlook until someone asks during an audit.

Building Access Controls That Actually Work

Effective ITAR foreign person access control requires both technical and administrative measures. The technical controls enforce restrictions; the administrative controls define what those restrictions should be and verify they're working. You need both.

Person Status Tracking

Start with a system that tracks ITAR person status separately from employment status. This doesn't need to be a specialized software tool—many companies use a field in their HR system or a separate database—but it needs to capture citizenship, permanent residency status, and any changes over time.

When someone's status changes (a foreign national becomes a lawful permanent resident, or a green card holder becomes a naturalized citizen), that change needs to flow through to access control decisions. I've seen cases where status changes were recorded in HR records but never updated in the access control matrix, leaving people with either too much or too little access.

Network Segmentation and Access Control Lists

Technical data subject to ITAR should be stored in network locations with explicit access controls based on person status. This might mean separate file servers, separate SharePoint sites, or separate cloud storage buckets with identity-based access policies that reference verified person status.

The implementation will vary by environment, but the principle is consistent: default-deny architecture where access to controlled data requires affirmative authorization based on verified U.S. person status. Role-based access control (RBAC) helps, but only if roles are defined with ITAR person status as a factor, not just job function.

DLP and Email Filtering

Data loss prevention tools can scan email, file transfers, and cloud uploads for content that matches ITAR-controlled data patterns. The challenge is defining those patterns accurately enough to catch real violations without generating so many false positives that people ignore the alerts.

In my experience, DLP works best when combined with data classification. If your engineers are tagging documents as ITAR-controlled during creation (or if your document management system is doing it automatically based on project association), DLP rules can enforce restrictions on how those tagged documents are shared and with whom.

Visitor and Contractor Management

Physical access to facilities where ITAR-controlled technical data is present also requires controls. Visitors, contractors, and temporary workers need to be screened for person status before being allowed into areas where controlled data might be visible, or you need to ensure that data is not accessible during their presence.

The common approach is visitor logs that capture citizenship information and either restrict access to certain areas or require escort by U.S. persons in areas where ITAR-controlled materials are present. The escort requirement only works if the escort actually prevents the foreign person from viewing controlled data—simply walking them through a room full of technical drawings isn't sufficient control.

Technology Authorization and the Foreign Person Exception

The ITAR regulations do provide a mechanism for foreign person access: Technical Assistance Agreements (TAAs) and other export authorization types. If you have a legitimate business need to provide controlled technical data to foreign persons—for example, working with a foreign subsidiary or partner—you can apply for authorization from the State Department's Directorate of Defense Trade Controls (DDTC).

The authorization process requires you to identify what technical data will be disclosed, to whom, for what purpose, and what safeguards will be in place. DDTC reviews the request and may approve, deny, or condition the authorization. The process takes time—often several months—and requires detailed documentation.

What doesn't work is discovering after the fact that you need authorization. If you've already provided access to foreign persons without authorization, that's a violation, and applying for authorization retroactively doesn't cure it. The time to think about whether you need a TAA or other authorization is during project planning, not during an audit.

For companies new to ITAR or expanding their defense work, understanding when registration is required is the first step. See ITAR Registration: Who Needs It and How to Get It Right for that foundational context.

What to Do When You Discover Unauthorized Access

Despite best efforts, violations happen. An employee forwards an email to the wrong person, a contractor accesses a file share they shouldn't have reached, a cloud misconfiguration exposes data to foreign national support personnel. When you discover unauthorized foreign person access to ITAR-controlled technical data, your response matters both for remediation and for how regulators will view the incident.

First, contain the exposure. Revoke access, remove data from unauthorized locations, and ensure no ongoing unauthorized access is occurring. Document what happened: who accessed what data, when, how the access occurred, and what data was involved.

Second, determine whether you're required to report the violation. ITAR § 127.12 requires registered persons to report any violation of the Arms Export Control Act or the ITAR. The reporting obligation isn't limited to major violations—it includes any violation. In practice, DDTC expects reporting of substantive violations, and unauthorized disclosure to foreign persons qualifies.

Companies sometimes hesitate to self-report, worried about enforcement consequences. The calculation is more nuanced than that. DDTC has made clear that voluntary disclosure and remediation are factors they consider in determining enforcement response. Discovering a violation during a government audit that you should have found and reported earlier is a worse position than proactive disclosure. For context on what enforcement can look like, see ITAR Violation Consequences: What Happens When Defense Contractors Get It Wrong.

Third, fix the root cause. If unauthorized access occurred because of a misconfigured permission setting, fix the configuration and verify similar settings across your environment. If it occurred because employees didn't understand the restrictions, provide training. If it occurred because you lacked visibility into who had access, implement auditing and monitoring. The corrective action should address the control gap that allowed the violation, not just the specific instance.

Building a Sustainable Foreign Person Access Program

One-time fixes don't create compliance. What's needed is an ongoing program that maintains visibility into who has access to ITAR-controlled technical data and ensures that access is limited to U.S. persons or properly authorized foreign persons.

Regular Access Reviews

Quarterly or semi-annual reviews of who has access to ITAR-controlled data repositories are essential. People change roles, person status changes (green cards are granted, employees separate), and system configurations drift. Access reviews verify that current access matches current authorization.

The review should cover file system permissions, application access, VPN profiles, cloud IAM policies, and any other technical control that governs access to controlled data. The output should be a documented certification that access is appropriate or a remediation plan for access that needs to be revoked or modified.

New Hire and Status Change Processes

Every new hire should be screened for ITAR person status before being granted access to controlled technical data. This means HR intake processes need to capture the necessary information and route it to whoever manages access provisioning for ITAR-controlled systems.

Similarly, when an employee's status changes—promotion, role change, immigration status change—that needs to trigger a review of access. Automated workflows help here, but only if the underlying systems are integrated and the triggers are properly configured.

Training and Awareness

Technical controls are only as effective as the people operating within them. Employees who handle ITAR-controlled technical data need to understand what the ITAR foreign person restrictions are, why they exist, and what they're required to do before sharing technical data with anyone.

Training should be specific, not generic. "Don't share ITAR data with unauthorized persons" is true but not particularly actionable. Better: "Before sending a technical drawing by email, verify the recipient's ITAR person status in [system]. If they're not a U.S. person and not listed on an approved TAA, do not send the data and contact [compliance contact] to discuss alternatives."

Annual training is common, but for organizations with high turnover or complex projects involving frequent data sharing, more frequent reinforcement is appropriate. Scenario-based training—here's a situation, what should you do—tends to be more effective than policy recitation.

The Strategic Implications for Leadership

ITAR foreign person compliance isn't just a legal checkbox—it affects your ability to operate in the defense industrial base. Unauthorized disclosures can result in significant fines, consent agreements that restrict business operations, and reputational damage that affects your ability to win contracts.

More fundamentally, it affects your talent strategy. If your workforce includes foreign nationals in engineering, technical, or support roles, you need infrastructure that allows them to contribute without accessing ITAR-controlled data, or you need to pursue export authorizations that permit their involvement. Both approaches have costs and constraints.

Some companies decide to restrict ITAR work to U.S. persons only, which simplifies compliance but limits your labor pool. Other companies invest in the infrastructure and processes to manage foreign person access through authorizations and technical controls, which preserves flexibility but requires ongoing investment and oversight. There's no universal right answer—it depends on your business model, your workforce composition, and your risk tolerance.

What doesn't work is ignoring the issue or assuming your current controls are adequate without verifying. The regulatory requirement is clear, the enforcement risk is real, and the operational impact of getting it wrong is significant. For executives considering whether their organization is positioned to handle these requirements, understanding what broader ITAR compliance entails provides necessary context.

If your company is pursuing or expanding defense work, treating ITAR foreign person access control as a strategic compliance function—not an IT task or an HR task—will serve you better than treating it as an afterthought. This is a leadership decision about risk management, operational design, and regulatory posture. It deserves executive attention and appropriate resource allocation.