Security
Frequently asked questions covering the security topics IT and security teams most often raise when evaluating a Connected Instrument Device (CID). Each answer is intentionally brief; where you need more, follow the More detail link to the relevant section.
Proposed as the first page under Security. The intent is to lead with crisp, customer-facing answers and let readers opt into depth through the links, rather than presenting granular internal detail up front. If accepted, remove this banner before publishing.
Security at a glance
us-east-1.Network and exposure
What does the CID expose on our network?
The CID presents a single IP address on your Corporate NIC with just two listening TCP ports: 443 (HTTPS / WSS, used by OpenLab CDS clients and the device's administrative web interfaces) and 22 (SSH, used only for Agilent support and protected by a password that rotates daily). Every other port is closed by default, so the device's network footprint is small and predictable. The CID behaves like a self-contained appliance rather than a general-purpose server — it does not advertise file shares, databases, or management services on your LAN. — More detail
Does the CID accept inbound connections from the internet?
No. All communication between the CID and the Hub is initiated outbound from the device over TLS, the same way a browser reaches a website. The Hub never opens a connection back into your network, so you do not need to create any inbound firewall rule, port-forward, or public IP for the device. If the CID loses connectivity it simply re-establishes its own outbound session when the network returns. — More detail
Is the embedded Windows VM reachable from our corporate LAN?
No. The Windows VM that runs OpenLab CDS has no IP address on your corporate LAN and cannot be reached directly by hosts on your network. It lives on an internal virtual network inside the CID, behind the device's reverse proxy, which forwards only the specific application paths that CDS clients need. This means the VM is not exposed to broad network scanning, lateral movement, or direct RDP/SMB access from your LAN. — More detail
Can we restrict or block SSH (port 22)?
Yes. Port 22 is used only for Agilent support access, so you are free to block it at your VLAN or firewall and open it only when a support session is needed. Even when it is reachable, the SSH account is protected by a credential that rotates automatically every day, so a captured password is not reusable. Blocking it has no effect on normal CDS operation or on the device's outbound connection to the Hub. — More detail
Data and privacy
Is our laboratory or sample data sent to the cloud?
No. Your chromatograms, results, methods, and sequences are created and stored locally and are handled entirely by OpenLab CDS on your network — they never traverse the CID ⇄ Hub boundary. What the device exchanges with the Hub is limited to operational metadata (device status, software versions, configuration) and the credentials needed to manage the appliance. The Hub is a management plane for the device, not a destination for your analytical data. — More detail
Is data encrypted in transit and at rest?
Yes, on both counts. Every connection between the CID and the Hub is protected with TLS in transit, including the management traffic and any brokered support session. On the Hub side, the database and the software-image storage are encrypted at rest using AWS-managed encryption. There is no point in the path where device-management data travels or is stored in clear text. — More detail
Is any PHI or PII transmitted to the Hub?
No PHI is involved at any point. The only personal data the Hub holds is the names and email addresses of the administrators you invite to manage your devices, which is stored on the Hub side in AWS Cognito and is never written to the device itself. No patient, sample, or end-user personal data is collected, transmitted, or stored by the CID or the Hub. — More detail
Where is Hub data hosted?
All Hub data is hosted in AWS us-east-1 (N. Virginia). A secondary Linux package mirror runs in us-west-2, but it carries only Agilent-built operating-system packages used for updates — it holds no customer data, device data, or credentials. So the only region where your device-management data resides is us-east-1. — More detail
How is our data kept separate from other customers?
The Hub is multi-tenant by design: every device, user, and record is scoped to your customer account, and that scope is enforced on every request. A signed-in user can only see and act on resources that belong to their own tenant — there is no shared view across customers. Your devices and their metadata are not visible to, or reachable by, any other organization using the Hub. — More detail
Identity and access
How is the device itself authenticated?
Each CID is issued a unique AWS IoT X.509 certificate at provisioning and uses mutual TLS to prove its identity to the Hub on every connection — both ends authenticate, not just the device. Because the identity is certificate-based and per-device, one device cannot impersonate another. Deleting the device in the Hub deactivates that certificate and detaches its policy, after which it can no longer connect. — More detail
How do users sign in to the Hub?
Administrators sign in through AWS Cognito at hub.cid.agilent.com over HTTPS. Passwords are never transmitted or stored in clear text, and idle sessions time out automatically after about 15 minutes so an unattended browser does not stay authenticated. Access is tied to your tenant, so each administrator only ever sees the devices that belong to your organization. — More detail
Is the Windows VM domain-joined? Can we apply our Group Policy?
No. The CID is a sealed, Agilent-maintained appliance, so the embedded Windows VM is intentionally not domain-joined and is not intended to receive your Group Policy. In place of the controls you would normally apply through GPO, Agilent centrally manages the VM's OS hardening, security patching, anti-malware, and credential rotation. This keeps the appliance in a known-good, supportable state and avoids configuration drift that could break CDS. — More detail
Remote support
How does Agilent access our device for support?
When support is needed, Agilent connects over AWS IoT Secure Tunneling, which is carried on the CID's own outbound connection — no inbound port is opened and no firewall change is required on your side. Critically, every session requires your per-device approval before it can start, can be ended by you at any time, and is recorded in the Hub Activity Log. This keeps remote support an explicitly consented, fully auditable action rather than standing access. — More detail
Updates and anti-malware
How are software updates and security patches delivered?
Updates are delivered centrally through the Hub as Agilent-signed, pre-tested bundles covering the Linux host, the Windows VM, OpenLab CDS, and instrument drivers. Because each bundle is validated by Agilent before release, you avoid the compatibility risk of patching CDS components piecemeal. You stay in control of timing — updates are applied within your own change-management window rather than being forced onto the device. — More detail
What anti-malware runs on the CID?
Agilent-managed anti-malware runs on both the Linux host and the Windows VM and is kept current through the Hub as part of the managed update stream. Because the CID is a sealed appliance, third-party endpoint agents cannot be installed on it — anti-malware coverage is provided and maintained by Agilent instead. This avoids the agent conflicts and performance issues that third-party tools can cause on instrument PCs. — More detail
Audit and compliance
Is there an audit trail of administrative actions?
Yes. The Hub Activity Log records who performed each administrative action, when it happened, and which CID it affected. The log is append-only, requires a reason to be entered when critical fields are changed, and is retained for at least seven years, so it supports both day-to-day review and long-term audit. You can use it to demonstrate exactly how each device has been managed over its lifetime. — More detail
Does deploying CDS on a CID change our 21 CFR Part 11 / Annex 11 compliance?
No. The regulated electronic records and their audit trails are produced and maintained by OpenLab CDS, and running that same CDS software on a CID does not change its documented Part 11 / Annex 11 posture. The CID is a managed platform for the software, not a replacement for the CDS records system. Your existing CDS validation and compliance approach continues to apply. — More detail
Decommissioning
What happens when we remove a CID?
When you remove a device in the Hub, the Hub deletes its record, deactivates its X.509 certificate so it can no longer connect, and signals the device to perform a factory reset on its next reboot. That reset wipes the local configuration and the device's identity, leaving nothing reusable behind. The result is a clean, auditable retirement of both the cloud-side identity and the on-device state. — More detail
Reporting a security concern
If you have a security question this page does not answer, or you need to report a potential security issue affecting a CID or the CID Hub, contact Agilent Support. Where applicable, include your tenant and the affected CID so the request can be routed quickly.
See also
- Security model: trust boundaries, attack surface, device and user identity, shared responsibility.
- CID Hub architecture: AWS service inventory, isolation, region, and encryption posture.
- Data flow and privacy: what does and does not cross the CID ⇄ Hub boundary, and retention.
- Remote access: console paths, the Agilent-support approval flow, and session controls.
- Traceability and compliance: Activity Log, retention, and regulatory positioning.
- System requirements: the authoritative networking, internet, and shared-responsibility tables.