Legacy JobBOSS and E2 Within the CMMC Boundary

The Question Most Legacy Shops Are Asking

A machine shop that performs defense work usually runs one shop management system at the center of its operations, and for a large share of the Defense Industrial Base that system is E2 or JobBOSS on a local server. When the contracts bring Controlled Unclassified Information into the shop, that data flows into quotes, job travelers, routings, inspection records, and purchase orders, and the database becomes a repository of CUI. The CMMC program, codified at 32 CFR Part 170 and effective December 16, 2024, then requires the 110 security requirements of NIST Special Publication 800-171 Revision 2, demonstrated through a Level 2 assessment. The question is whether a legacy system can meet that bar without being replaced.

Because the system runs on hardware the shop owns, there is no cloud provider carrying any part of the load. Every applicable requirement, across the database, the operating system, the endpoints, any service providers, and the physical room the server sits in, is the contractor's to implement, assign, and evidence. That is the burden, and it is also the reason a shop that builds those controls deliberately can keep a system it knows and relies on.

The Database Engine Sets the Path

The shop management application sits on a database, and the engine determines how the most technical requirements are met. E2 has historically run on either Microsoft Access or Microsoft SQL Server. Classic JobBOSS in its Professional and Enterprise editions runs on SQL Server. The oldest installs may sit on a file-based or Pervasive and Actian PSQL engine. A file-based engine does not provide the server-side encryption, auditing, and access-control model that SQL Server offers, so a shop on Access usually has to supply those protections beneath the database or migrate to SQL Server.

Even on SQL Server, the edition and version matter. Native transparent data encryption was available only in the Enterprise and Developer editions from the 2008 release through the 2017 release, and it reached the Standard edition only with SQL Server 2019. A shop on SQL Server 2016 or 2017 Standard edition cannot use native transparent data encryption and has to rely on full-volume encryption beneath the database. Establishing the exact edition and version is the first technical step.

Encryption, Audit, and Access Live in the Layers Around the Application

Encryption at rest comes from transparent data encryption on a supporting SQL Server edition, or from BitLocker full-volume encryption beneath the database, with the host operating in FIPS mode on a validated cryptographic module. Encryption in transit is a separate requirement, satisfied by forcing transport encryption at the SQL Server engine with a trusted certificate, because transparent data encryption does not protect the connection between the workstation client and the database. On the oldest installs, the client driver may predate TLS 1.2 and require updating before transport encryption is enforced.

Audit and accountability is evidenced below the application, because legacy shop systems rarely produce records that satisfy the full requirement on their own. SQL Server auditing and Windows event logging carry the load, and the recurring trap is the shared login that defeats individual traceability. Access control and multifactor authentication operate above the application, at the operating system and identity layer through which users reach the server, mapped to each access path rather than expected from the ERP itself.

Exports Carry the Same CUI

The boundary is not only the server. Every workstation, shop-floor terminal, and administrative laptop that reaches the database is in scope, and so is what leaves the system as output. Reports, spreadsheets, job travelers, inspection packages, purchase orders, and copied database extracts often carry the same CUI as the live database, and in many shops these files spread far more freely than the database itself. Once exported, they have to be protected under the same access control, transmission, media protection, and retention rules that apply to the source system, which is why the data-flow map has to follow the exports and not only the database.

The Pattern Beyond One Product

Although this paper works through a specific pair of products, the situation is not unique to E2 or JobBOSS. Other shop management and manufacturing execution systems, older quality and inspection databases, computer-aided design and product lifecycle systems, and custom in-house applications present the same structure when they hold CUI. The application is where the data lives, but the controls that protect it operate around and beneath it. The method generalizes: confirm whether the application holds CUI, identify the data store and the platform beneath it, establish whether that platform is still supported, build the controls in the surrounding layers, follow the data to its exports and any service providers, assemble the evidence, and modernize only where the platform can no longer support the controls.