Yes, but it should be tightly limited. In most aerospace environments, the safest approach is not broad system access. It is controlled, read-only, time-bound access to a defined evidence set, or supervised review sessions when direct access would expose regulated data, unrelated programs, or validated production functions.
What is appropriate depends on the auditor type, the systems involved, the sensitivity of the data, and how well your identity, authorization, logging, and segregation controls are actually implemented. A method that is acceptable for one plant or audit scope may be inappropriate for another.
What a safe approach usually looks like
-
Provide least-privilege access. Limit the auditor to the minimum records, workflows, sites, and date ranges needed for the audit.
-
Use read-only roles wherever possible. Auditors generally do not need the ability to change records, release documents, acknowledge alarms, or trigger transactions.
-
Make access time-limited. Use temporary accounts, approved access windows, and automatic expiration.
-
Segment by system and data domain. Keep auditors out of unrelated programs, export-controlled data, supplier data, personnel data, and engineering content that is outside scope.
-
Require strong identity controls. Named accounts, multi-factor authentication where supported, and no shared credentials.
-
Log and retain activity. Record sign-in events, viewed objects where feasible, exports, and privilege changes so the review itself is traceable.
-
Control downloads and exports. In some cases screen sharing or supervised review is safer than allowing file export.
-
Use an evidence workspace or replica when practical. Many companies expose approved records through a portal, reporting layer, document vault, or packaged evidence set rather than the live transactional system.
Common constraints in aerospace environments
The main risk is not just unauthorized access. It is overexposure of adjacent data and functions in complex, integrated environments. Brownfield stacks often connect MES, ERP, PLM, QMS, document control, calibration, and identity systems in ways that were not designed for external access. Even when a vendor offers an auditor portal, the real question is whether your roles, data mappings, and segregation rules are reliable enough to use it safely.
There are also validation and change-control concerns. Creating a new external role, exposing a new interface, or altering permissions in a regulated environment may require formal review, testing, and controlled deployment. If your access model is immature, the safer option may be curated evidence review instead of direct login.
Export controls and contractual restrictions may further limit what can be shown remotely. That assessment is organization-specific and should be handled through your established security, compliance, and program governance process.
When direct auditor access is a bad idea
Direct system access is often the wrong choice if any of the following are true:
-
Your systems cannot reliably enforce read-only, object-level, or program-level segregation.
-
The audit scope crosses legacy applications with inconsistent user models or weak logging.
-
Access changes would affect validated production configurations without adequate testing and approval.
-
The environment contains export-controlled, defense-related, customer-restricted, or unrelated proprietary data that cannot be cleanly separated.
-
You depend on shared service accounts, generic terminals, or incomplete audit trails.
-
The audit can be satisfied with approved reports, record packages, screen-share walkthroughs, or supervised evidence retrieval.
In those cases, a supervised review model is often lower risk and easier to defend operationally.
Why full replacement is usually not the answer
If current systems make auditor access awkward, replacing the whole stack is rarely the practical fix. In aerospace and other long-lifecycle regulated environments, full replacement often fails because of qualification burden, validation cost, downtime risk, integration complexity, and the need to preserve traceability across legacy processes and assets. It is usually more realistic to add controlled access layers, reporting views, or evidence workflows around existing MES, ERP, PLM, and QMS platforms.
Practical operating model
A workable model usually includes:
-
an approved access request and review process
-
predefined auditor roles by audit type
-
documented data scope and exclusions
-
temporary provisioning with expiration
-
test verification before the audit window
-
active monitoring during the audit
-
post-audit access removal and log review
This does not guarantee an acceptable audit outcome. It reduces avoidable security, traceability, and change-control failures while making the evidence review more manageable.