EAR technology access needs a release-event ledger

Start with the technology and the release event

The direct operating answer is to govern the potential release, not merely the repository. Part 734 distinguishes an actual shipment or transmission from a release of technology or source code to a foreign person, and section 734.15 identifies inspection and oral or written exchange as possible release methods. A file can remain on a U.S. server while a person sees controlled detail, and a person can receive technology through a conversation, screen, model, drawing, source repository, service session, or physical inspection without receiving a conventional attachment. ^[1]

Create a release-event record that identifies the item, technology or source code, technical scope, classification and control basis where established, current version, owner, system or physical location, proposed recipient, recipient role and organization, person-status evidence, relevant country analysis, place, date, access method, intended purpose, visible fields or functions, access information, applicable authorization or exception analysis, approver, conditions, actual event, and revocation or reassessment trigger. Unknown classification, identity, status, or scope should stop the conclusion rather than default to unrestricted.

Separate account permission from observed release

A role, repository permission, badge, meeting invitation, support account, download link, or valid credential can establish a capability to reach information without proving what was released. Conversely, a release may occur during an inspection or exchange that leaves no download log. Maintain the planned access decision separately from the observed session. Reconcile identity-provider events, application logs, file and object audit history, screen-sharing or support records, meeting and visitor records, repository changes, and accountable witness or user confirmation where appropriate. ^[1]

Status labels should distinguish requested, awaiting classification, awaiting person review, authorized with conditions, provisioned, accessed, inspected, exchanged, denied, expired, revoked, and under investigation. Record the exact technology scope for each state. A user who may see one approved build, field set, project, or technical topic does not inherit authority for a later revision, another project, unpublished source code, troubleshooting output, or an oral discussion that reveals different information.

Apply the encrypted-storage boundary exactly

Section 734.18 provides a bounded rule for sending, taking, or storing unclassified technology or software secured with qualifying end-to-end encryption and cryptographic controls, when it is not intentionally stored in a Country Group D:5 country. The section also states that ability to access qualifying encrypted technology or software does not itself constitute release or export. That is not a generic encryption safe harbor. The record must establish every relevant condition under the current rule and preserve the architecture and facts on which the analysis relied. ^[1]

Document data classification, encryption boundary, cryptographic module and version, key creation and custody, who can decrypt, service-provider access, client and server behavior, backups, replicas, caches, disaster recovery, intended and observed storage regions, routing, endpoint protections, logging, exceptions, and changes. Keep encrypted possession, possession of access information, decryption capability, and actual plaintext release separate. Section 734.19 also gives access-information transfers their own rule when made with knowledge that the transfer would cause an unauthorized release. ^[1]

Test access paths that do not look like exports

A representative evaluation should cover an engineer viewing equipment, a remote support screen, an oral design discussion, a source-code repository invitation, an encrypted cloud backup, an administrator who holds keys, a link forwarded to another person, a recipient whose status changes, and a person whose approved project scope expands. Reviewers should reproduce the technology classification and version, person and country analysis, rule version, approval, provisioned path, actual release evidence, denied attempts, changed facts, revocation, and downstream investigation without treating account creation or file geography as the whole event.

The current eCFR Part 734 page supports the attributed export, deemed-export, release, encrypted-storage, encrypted-access, and access-information distinctions. It does not classify particular technology or software, establish a person's status or relevant country, decide whether an activity is subject to the EAR, determine a license or exception, validate an encryption design, or authorize any disclosure. This decision is distinct from Trade Controls Brief's earlier Part 734 de minimis analysis: that article governs controlled U.S.-content calculations in a foreign-made item; this one governs a person-specific technology or source-code release event. ^[1]

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

Trade Controls Brief will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.