Skip to main content

Security

This page answers the security questions that IT and security teams most often raise when evaluating a Connected Instrument Device (CID).

Security at a glance

No inbound accessThe CID opens no inbound path from the internet; all Hub communication is CID-initiated outbound TLS.
Your lab data stays localChromatograms, results, and sequences never leave your network; only operational metadata reaches the Hub.
Encrypted in transit and at restAll CID ⇄ Hub traffic is TLS-encrypted; Hub data is encrypted at rest in AWS us-east-1.
You control remote supportEach Agilent support session needs your per-device approval and is recorded in the Activity Log.
Centrally patched and fully auditableAgilent delivers signed, pre-tested updates through the Hub, and an append-only Activity Log is retained for at least 7 years.

Network and exposure

What does the CID expose on your network?

The CID presents a single IP address on your Corporate NIC with just two listening TCP ports. Port 443 carries HTTPS and WebSocket Secure (WSS) traffic for OpenLab CDS clients and the device's administrative web interfaces. Port 22 carries SSH, which is used only for Agilent support and is 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, and it does not advertise file shares, databases, or management services on your LAN. For more, see Attack surface in the Security model.

Does the CID need 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. You do not need to create any inbound firewall rule, port-forward, or public IP for the device. If the CID loses connectivity, it re-establishes its own outbound session when the network returns. For more, see Trust boundaries in the Security model.

Does the CID Hub make inbound connections to your network?

No. The Hub never opens a connection back into your network. Every exchange rides the outbound session the CID initiates, so there is nothing on your side for the Hub to connect to. For more, see Trust boundaries in the Security model.

Is the embedded Windows VM reachable from your 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 Remote Desktop Protocol (RDP) or Server Message Block (SMB) access from your LAN. For more, see Attack surface in the Security model.

Can you restrict or block SSH (port 22)?

Yes. Port 22 is used only for Agilent support access, so you can 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. For more, see Attack surface in the Security model.

Data and privacy

Is your laboratory or sample data sent to the cloud?

No. Your chromatograms, results, methods, and sequences 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. For more, see At a glance in Data flow and privacy.

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. For more, see Encryption posture in the CID Hub architecture.

Is any protected health information (PHI) or personally identifiable information (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. For more, see At a glance in Data flow and privacy.

Where is Hub data hosted?

All Hub data is hosted in AWS us-east-1 (N. Virginia), which is the only region where your device-management data resides. For more, see Region and data residency in the CID Hub architecture.

How is your 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, and 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. For more, see Multi-tenancy and isolation in the CID Hub architecture.

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, so 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. For more, see Device identity in the Security model.

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 repeated failed sign-in attempts temporarily lock the account, which protects against password guessing. Idle sessions are logged out automatically after 10 minutes of inactivity, with a 30-second warning, so an unattended browser does not stay signed in. Access is tied to your tenant, so each administrator only ever sees the devices that belong to your organization. For more, see CID Hub user identity in the Security model.

Is the Windows VM domain-joined? Can you apply your 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 Group Policy Objects (GPOs), 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. For more, see Posture versus a domain-controlled lab PC in the Security model.

Remote support

How does Agilent access your device for support?

When you request support, Agilent connects through AWS IoT Secure Tunneling, which uses the CID's existing outbound connection. You do not need to open inbound ports or change your firewall. Each session starts only after you approve it for that device, you can end it at any time, and the Activity Log records it. An approval covers only that one session: when the session closes, the authorization expires, and any further access requires a new request and a new approval. A session that is left open expires automatically after 12 hours. Remote support happens only when you allow it, and you always have a complete record of each session. For more, see AWS IoT Secure Tunneling in Remote access.

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, this avoids the compatibility risk of patching CDS components piecemeal. You stay in control of timing, and updates are applied within your own change-management window rather than being forced onto the device. For more, see Software delivery from the Hub in the CID Hub architecture.

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, and 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. For more, see Posture versus a domain-controlled lab PC in the Security model.

Audit and compliance

Is there an audit trail of administrative actions?

Yes. The 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 7 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. For more, see Activity Log in Traceability and compliance.

Does deploying CDS on a CID change your 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. For more, see Compliance posture in Traceability and compliance.

Decommissioning

What happens when you 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. This retires both the cloud-side identity and the on-device state. For more, see Decommissioning and offline devices in the Security model.

Further questions and inquiries

This page gives a broad overview of how the CID and the CID Hub keep your data secure, but security is a detailed subject and not every topic is covered here. Contact your Agilent account team or Agilent Support if you need more information, for example to complete a vendor security assessment or questionnaire, or to discuss a requirement specific to your environment. To report a potential security issue affecting a CID or the CID Hub, contact Agilent Support and include your tenant and the affected CID so the request can be routed quickly.