EAR Compliance Visitor Management for Dual-Use Technology Sites

Getting this boundary right is the first compliance decision, and vendor pages rarely help. ITAR (22 CFR, administered by the State Department's DDTC) governs defense articles and defense services on the US Munitions List (USML). EAR (15 CFR, administered by the Commerce Department's BIS) governs "dual-use" and purely commercial items — hardware, software, and technology that has civil applications but could also support a military or proliferation end use. Most manufacturers, electronics firms, semiconductor and materials companies, and commercial-software teams fall under EAR, not ITAR.

Under EAR, items are classified by an Export Control Classification Number (ECCN) on the Commerce Control List (CCL); anything subject to the EAR but not listed with a specific ECCN is designated EAR99. The visitor-access risk is the same shape under both regimes: releasing controlled technology or source code to a foreign person located inside the United States counts as an export to that person's country of most recent citizenship or permanent residency. That is the "deemed export" rule (15 CFR §734.13(b)), and the release definition in §734.15 is broad enough that a plant tour, a vendor walkthrough, or an unescorted contractor in a lab can trigger it.

InstaCheckin does not decide which regime you are under, and it does not classify your items. What it does is give either program the same clean artifact: a structured, timestamped, photographed visit record, attributed to a named US-person host, filterable by citizenship and exportable whenever a compliance officer or BIS reviewer asks.

Start with the boundary. InstaCheckin is a visitor-logging system, not an export-control decision engine. It records the facts your export-compliance manager needs — who arrived, when, the citizenship they attested to, the US-person host who signed for them, the NDA or technology-control acknowledgment they accepted, the badge they wore, and when they signed out — and it exports that record on demand. Those facts support an EAR program. They do not constitute one, and no visitor system can.

Be precise about what stays with your people and your technology-control plan. InstaCheckin does not determine whether a visitor requires a deemed-export license before seeing controlled technology. It does not classify items or technology under the CCL or assign an ECCN. It does not screen names automatically against the BIS Entity List, the Denied Persons List, the Unverified List, or OFAC's SDN list. It does not physically gate a door or enforce continuous escort. And it does not warrant that any single feature satisfies any specific EAR section. What it guarantees is a clean artifact: a structured, timestamped, photographed visit record, attributed to a named US-person host, exportable whenever a reviewer asks.

EAR compliance involves more than visitor logs alone. Consult your export-compliance officer or counsel for a complete program. This page describes product features, not legal advice.

The deemed-export rule (15 CFR §734.13(b)) treats the release of controlled technology or source code to a foreign person in the United States as an export to that person's home country. "Release" under §734.15 includes visual inspection of controlled technology, oral or written exchange of technical data, and the application of knowledge — exactly the kinds of exposure that happen during an uncontrolled site visit. The moment a foreign-person visitor crosses into an area where controlled technology is visible without the required authorization, you may have an export event on your hands.

Export-compliance reviewers keep the same checklist on every audit: who entered the building, when, who their US-person host was, what citizenship they attested to, what NDA or technology-control acknowledgment they signed, what badge they wore, which areas they were cleared for, and when they signed out. Paper logbooks satisfy the literal "keep a record" requirement and almost nothing else — illegible, trivially back-dated, impossible to search or filter by citizenship.

The EAR recordkeeping rule (15 CFR Part 762) requires covered records be retained for five years from the relevant date. A structured digital sign-in system collapses the reviewer's checklist into a single record per visit and keeps it retrievable for the whole window. Every check-in writes the same fields, every visitor is photographed, every host is named, every entry timestamped. When the reviewer asks for "the last twelve months of foreign-person visits to the cleanroom," it is one filtered export instead of a week of transcribing a paper binder.

The iPad welcome flow can require a visitor to attest to their citizenship or permanent-residency status before the sign-in completes. Companies typically configure a required field — "Are you a US citizen or lawful permanent resident?" — with a yes/no or country-of-citizenship picker. The attestation is captured on the same record as the visitor name, host, photo, and signature, so the export-compliance manager can later filter the log by foreign-person status without any post-hoc reconciliation.

When a visitor selects a non-US, non-permanent-resident status, the InstaCheckin iPad app routes the check-in into a different workflow: a stricter NDA, a "do not enter controlled areas without escort" warning, an additional host-approval step, or a different badge template. It is the same conditional-flow engine offices use for "contractor vs. interview candidate vs. delivery driver," pointed at a deemed-export decision. One honest caveat: the attestation is the visitor's own statement, captured and timestamped — it is a record, not an identity verification. InstaCheckin does not scan a passport or run background identity checks; verifying the attestation and making the deemed-export licensing determination is your program's responsibility.

Every visitor record in the InstaCheckin admin portal binds a check-in to a specific host employee. For EAR-covered sites, that host is the US person responsible for escorting the visitor and keeping them away from controlled technology they are not authorized to see. Their name, email, and phone number sit on the visit record, and they receive an email, SMS, Slack, or Microsoft Teams notification the moment the visitor signs in — so the escort is present rather than paged after the fact.

The host-of-record field becomes the audit lookup that matters. If a foreign-person visit is later flagged in review, the export-compliance manager can pull every visit hosted by that employee, every visitor they escorted, and every facility they signed in at — without joining badge-system data to a separate spreadsheet. It answers the BIS question directly: who accepted responsibility for this person while they were inside the controlled space.

Most companies with EAR exposure prefer to validate visitor information before the visitor arrives — not during a 90-second iPad sign-in with a queue forming behind them. InstaCheckin lets a host or compliance manager pre-register a visit from the admin portal, send the visitor a pre-arrival email with a unique check-in link, and require them to confirm citizenship, work authorization, and a program-specific NDA or technology-control plan (TCP) acknowledgment in advance.

The pre-registration flow is where you attach the badge template, the escort-required flag, and the conditional NDA. By the time the visitor scans their QR code at the kiosk, the workflow already knows whether they attested as a US person, whether they need an escort, and which project they are visiting. The acknowledgment is displayed at sign-in, captured with a fingertip or stylus signature, timestamped, and stored on the visit record; signed documents can sync to Google Drive, Dropbox, or OneDrive so legal and compliance both hold a copy. Electronic-record and e-signature law varies by jurisdiction; verify enforceability with counsel. The lobby stays under a minute even when the back-end record is doing the heavier compliance work.

Every InstaCheckin check-in captures a visitor photo from the iPad front camera. The photo is stored on the visit record and printed onto a visitor badge from a connected Brother QL-820NWB or compatible Brother QL-series label printer (810W, 720NW). For EAR-relevant visits, the badge template can carry a high-contrast "ESCORT REQUIRED" overlay, the host's name, a project code, and a color band that distinguishes a foreign-person badge from a US-person badge at a glance.

Here honesty matters: InstaCheckin makes the escort requirement visible and binds the US-person host of record — it does not physically enforce continuous escort or gate a controlled-area door. Physical enforcement stays with your facility. What the tool contributes is legibility: an engineer walking past the CCL-controlled bench does not need to memorize who can be where, because a red-banded escort-required badge with no US-person host nearby is a flag any floor lead can act on.

This is where honest positioning separates a usable EAR record from a compliance liability. Many visitor management vendors advertise automated screening against government restricted-party lists — the BIS Entity List, the Denied Persons List, the Unverified List, and OFAC's Specially Designated Nationals list. InstaCheckin does not do automated list screening, and this page will not pretend that it does.

What InstaCheckin offers is a manual blocklist. Your compliance or security team adds names of individuals who must not be granted access — a party your restricted-party screening has already flagged, a terminated employee, anyone flagged by counsel — and when a matching name attempts to sign in at the iPad, InstaCheckin silently alerts your designated security contact while the visitor is still at the kiosk. The visitor sees a normal sign-in screen; the response happens in the background.

The distinction matters. Automated restricted-party screening is a real, separate control, and under EAR it is a screening obligation you cannot delegate to a visitor logbook. If your program requires it, run it in a dedicated screening tool and record the result — InstaCheckin is not that control. InstaCheckin's job is the structured visit record and the manual watchlist your team maintains by hand. Confusing the two is how audit findings happen; naming the boundary is how you avoid them.

The InstaCheckin admin portal stores every check-in as a structured record with the same fields populated every time: visitor name, company, photo, citizenship attestation, purpose of visit, host of record, badge ID, NDA or TCP signature, sign-in and sign-out timestamps, and facility location. The full log exports to CSV, Excel, or PDF from the dashboard with date-range and citizenship filters applied as needed.

Companies typically pull a quarterly export and hand it to the export-compliance manager for review. When BIS or an internal audit team asks for "the last twelve months of foreign-person visitor records to this facility," the export is one filter and one click. The record is retained server-side for as long as your data-retention policy specifies — which is how customers keep records available across the EAR five-year recordkeeping window (15 CFR Part 762). Two honest notes: InstaCheckin does not itself set or enforce a five-year retention clock — you configure retention to your policy — and the log is a server-stored digital record that is far harder to lose or back-date than a paper binder, but it is not a cryptographically sealed, tamper-proof ledger. If your program requires immutable write-once records, treat that as a separate control.

Commercial-technology and manufacturing firms typically run multiple facilities — a headquarters, a few engineering or production sites, a distribution center, maybe a contract-manufacturing partner's floor. The InstaCheckin admin portal supports a multi-site dashboard where a corporate export-compliance team can see check-ins across every location, run a unified audit export, and push a consistent badge template, NDA, and pre-registration flow to every site.

Per-site configuration still works the way local teams expect: each location can override the welcome screen, badge color, host directory, and NDA wording. We describe the same multi-site pattern, plus the controlled-production-floor visitor flows, on the manufacturing visitor management page, and the defense-article equivalent on the ITAR visitor management page.

InstaCheckin ships product features companies use as part of their EAR program — citizenship attestation, host-of-record binding, pre-registration with conditional flows, NDA and technology-control acknowledgment capture, photo capture, badge differentiation, a manual blocklist, and audit-log export. Customers running ITAR-controlled and C-TPAT (supply-chain) workflows reuse the same features for their own recordkeeping.

EAR compliance involves more than visitor logs alone. Consult your export-compliance officer or counsel for a complete program. This page describes product features, not legal advice. InstaCheckin does not classify technology under the CCL, does not assign ECCNs, does not determine whether a deemed-export license is required, does not run automated restricted-party screening, does not file license applications, and does not warrant that any single feature satisfies any specific EAR requirement on its own. Authoritative BIS guidance lives at bis.doc.gov.

For background on iPad-based check-in patterns, see the iPad kiosk mode pillar, the visitor sign-in system glossary, and the best visitor sign-in app comparison. The office visitor management page covers less-regulated visitor flows.