IT approval and frequently asked questions
Use this chapter with the release manifest, the customer's network matrix and the agreed deployment profile. It explains the Print Bridge boundary; approval of this component is not approval of every cloud, AI or machine-integration feature.
What should the approval pack contain?
| Evidence | Required detail |
|---|---|
| Architecture | Host, assigned site/environment, cloud origin, approved printer network and ownership. |
| Release | Version, supported OS/architecture, installer hash, publisher/signature, component inventory and test evidence. |
| Service | Account, privileges, state/log paths, ACLs, startup/recovery policy, resources and uninstall procedure. |
| Network | Initiator, destination hostname/IP, protocol/port, proxy/CA requirements and update distribution. |
| Data | Label fields, local journal/log content, cloud storage, retention, deletion and backup responsibilities. |
| Operations | Update window, rollback, vulnerability contact, incident process, support access and physical acceptance. |
Use a separate copy for each deployed version and environment. A sample policy, generated SBOM or source-code review is not proof of the customer's installed configuration.
Which operating systems and deployment sizes are targeted?
The Windows x64 package targets Windows 11 and Windows Server 2022/2025. Windows-host execution and service acceptance must be completed before declaring a released support matrix. Linux packages target x64/arm64 systems compatible with bundled Node 24, glibc and systemd; qualify the customer's distribution separately. Node and the service host are bundled, so the customer does not install a development toolchain.
Use an always-on host. One bridge supports up to 256 active printers and serializes work per printer. Copies, label size, job lifetime and response size are bounded. Measure memory, throughput and event-to-label latency with the customer's actual labels before sizing or promising an SLA. No cluster, automatic host failover or physical-printer performance certification is implied.
Does it require administrator rights?
Installation and changes to the IT-managed local policy require host administration. Windows uses LocalService; Linux uses the dedicated ennea-print account. Configuration is administrator/root-owned and service-readable; protected state is service-writable. Verify effective ACLs on the target host before commissioning. Operators work through Ennea and do not need server administration. Exact paths and commands are in Install the Print Bridge.
Does it require inbound firewall rules?
The standalone print service initiates outbound HTTPS to the configured Ennea API and outbound connections to approved printers. It has no inbound printing or management listener. The full machine Edge Runtime has different local interfaces and requires a separate network review. See the network matrix.
Can cloud configuration reach other local devices?
The local policy limits literal addresses/CIDRs and ports. Jobs use registered printer IDs; their destination must match that policy. IT can mirror the boundary in host and network rules. Preapproving a dedicated printer subnet and selected ports can reduce later approval tickets without allowing a general LAN connection path.
Is the printer traffic encrypted?
The cloud connection uses HTTPS with certificate verification. The implemented raw TCP printer adapter sends unencrypted ZPL/TSPL and does not authenticate the printer. Apply segmentation and approved destination rules. Do not claim end-to-end encryption for this LAN hop. A secure printer protocol requires a supported adapter and device-specific verification.
Does it work through our proxy and EDR?
Provide the exact deployment's API hostname and release-distribution endpoints to IT. Set NODE_USE_ENV_PROXY=1, HTTPS_PROXY and NO_PROXY in the service environment for an HTTP(S) proxy. NTLM/Kerberos proxy authentication is not implemented. Add a PEM CA with NODE_EXTRA_CA_CERTS or use NODE_USE_SYSTEM_CA=1; restart the service after changes. Linux reads /etc/ennea-print-bridge/environment; Windows needs service-specific environment configuration. Protect proxy credentials and exclude them from support evidence.
Validate proxy, certificate trust and endpoint protection with the released package. Do not disable certificate validation or grant unrestricted outbound access as a workaround. Compatibility must be evidenced for the actual environment.
What data leaves the site or reaches AI?
The existing Ennea deployment already processes the source business data according to its configured data flows. Bridge synchronization exchanges configuration, health and job receipts; the bridge receives only rendered labels and delivery metadata, not entire orders. Labels themselves may contain names, addresses or other personal data when configured that way.
The print service does not need an AI provider to transmit a label. If Konnie or an AI action is involved upstream, record its provider, region, purpose and terms separately. Do not infer that all processing remains local merely because printers or the platform are on premises.
How are credentials, data and logs protected?
Enrollment uses an expiring single-use code; the runtime uses a separate revocable credential. Windows protects credentials with machine-bound DPAPI and ACLs. Linux uses AES-256-GCM, a mode-0600 key and a mode-0700 state directory; this does not protect against root or service-account compromise. Apply the host's disk-encryption policy as well. Logs and diagnostics exclude label contents and secrets.
The local journal contains delivery metadata, without label contents. Acknowledged terminal entries expire after 7 days of age during successful sync; unacknowledged receipts remain. Cloud jobs become eligible for managed expiry after 90 days by default, subject to holds and deletion approval. Windows rotates each WinSW log stream across three 1-MiB files; Linux log retention follows customer journald policy. Backups, incident evidence and exported labels need their own retention decisions.
Who controls updates and support access?
Customer IT distributes the approved version and chooses its maintenance window. Use release hashes/signatures, preserve state and retain a compatible rollback package. A source build is not an organization-signed release. Provide the release-specific component inventory/SBOM, dependency scan and remediation record; external penetration-test evidence is separate.
Pairing does not grant a general remote shell. Support access must be separately authorized, scoped and logged according to the customer agreement. Redacted diagnostics are the normal first evidence. Define one Ennea incident contact and one customer IT owner.
What happens offline or after a reboot?
The bridge keeps a durable journal and retries acknowledgement delivery independently of physical printing. Jobs have expiry and configuration revisions. A recovered send with uncertain physical outcome is marked Unknown and requires reconciliation. It is not automatically printed again. See Jobs and recovery.
How do we monitor it?
Operations Studio shows bridge contact, printer connection observations and job outcomes separately. Bridge online state uses a recent heartbeat; a reachable TCP socket is not a paper/stock sensor. Monitor the Windows service or systemd unit through the customer's existing monitoring system, and collect redacted diagnostics for incidents. The bridge exposes no inbound monitoring or management listener.
Can we disable or remove it?
IT can stop the local service or block its approved routes; an authorized Ennea administrator can revoke the bridge. Reconcile jobs that may already have been sent, uninstall using the release procedure, then remove credentials and retained state under the agreed deletion policy. Keep audit evidence where required; revocation cannot recall physical labels.
Which standards and rules should we discuss?
- ISO/IEC 27001 addresses organizational information-security management. State the actual certification scope and evidence; this guide does not establish certification.
- ISA/IEC 62443 addresses industrial automation/control-system cybersecurity. Its system, component and lifecycle requirements are particularly relevant to machine-network deployments; agree the applicable scope with the customer's OT owner.
- TISAX may be required by automotive customers. Share actual scoped assessment evidence when available.
- GDPR processing terms, technical/organizational measures, subprocessors and transfer arrangements depend on the actual label/source data and deployed providers. Agree them with the customer's controller and relevant privacy owners.
- Assess applicability of the EU Cyber Resilience Act for distributed software. Its main provisions apply from 11 December 2027 and Article 14 reporting provisions from 11 September 2026. Product-specific duties require an applicability assessment.
These references are a requirements map, not a bundle of certifications automatically granted by installing the bridge.
Commissioning checklist
Confirm the installed release and identity, restricted network policy, current printer revision, live authorization/revocation, startup after host reboot, expiry after an outage, acknowledgement recovery, update/rollback and redacted diagnostics. Finish with a real label on each accepted stock/DPI combination and a successful scan. Record Windows-host and physical-printer evidence separately from software-only tests.