# Equipment access

> The certificates of the OPC UA equipment the Connector dials: what waits for approval, what is approved, what is blocked, importing a certificate ahead of the first connection, and what a waiting device says in the Connector.

Equipment access is the one row of the OPC UA EQUIPMENT group on the Settings page: the outgoing half of certificate trust. When the Connector dials an OPC UA equipment server, that server proves who it is with a certificate, and the station reads nothing from equipment whose certificate you have not approved. The card head says it: "When the Connector dials an OPC UA equipment server, that server proves who it is with a certificate. Approve only a fingerprint you have checked with whoever commissioned the equipment." Opening the page takes the **Change settings** permission; decisions are taken on the station's own desktop.

The principle under the head: "Nothing is read from equipment you have not approved. A device whose certificate is waiting here stays silent and says so in the Connector. Approving it starts the reading; withdrawing the approval closes the session and asks you again. Certificate names are claimed by the equipment; the SHA-256 fingerprint is the identity to verify."

The card is deliberately the same shape as [Client access](settings-opcua-client-access), with the same words wherever the idea is the same, and the same rule for who may decide: a browser on another device sees "Equipment access can only be changed in the station's desktop app." and the banner "Open the desktop app to change equipment access"; a role without Change settings, a running unit, a stopped runtime and a change already in progress each refuse with their own sentence. Every outcome lands in the status bar.

## What a waiting device does in the Connector {#what-a-waiting-device-does-in-the-connector}

The first time the Connector dials an OPC UA device, the equipment's certificate is refused, recorded here as waiting, and the device reads nothing. On the [device's page](connector-devices) the Connector shows a caution banner, **Waiting for certificate approval**, with a **Review certificate** button that opens this section on the device's row, and the device's health names the same state in the tree. The driver's own failure says the reason instead of a nameless handshake error: "This equipment's certificate (the first 16 characters of the fingerprint) is waiting for your approval under Settings, Equipment access. Reading starts once you approve it." A blocked one reads "…is blocked at this station. Review it under Settings, Equipment access." The discovery browse passes the same gate before its session opens.

Once approved, the Connector starts reading on its next attempt. Equipment that was reading and starts presenting a different certificate at the same address stops being read and raises a sticky card, "Certificate changed: `<name>`": "The equipment at `<address>` was reading with a certificate this station approved and is now presenting a different one (…), so nothing is read from it. Check the fingerprint with whoever maintains the equipment, then approve it.", with **Review**, plus a Windows notification for a hidden window. A device being registered right now is not announced this way: whoever registers it is already looking at the Connector.

## Waiting for approval {#waiting-for-approval}

Drawn while at least one certificate waits, headed "These devices stay unread until you decide." with the count. Each row shows an amber dot, the name the certificate claims, "Claimed equipment identity", the fingerprint, "`<address>` · Last attempt `<date and time>` · N connection attempt(s)", and a **Certificate details** disclosure with Subject, Issuer, Application URI, Domain names, Valid from, Valid until and First seen. The row a Review button led to is marked "Selected for review" and scrolled into view.

| Command | What it does | Greyed when (situation) |
| --- | --- | --- |
| Approve | Moves the certificate to Approved equipment and refreshes the live validator: "`<name>` is approved. The Connector starts reading on its next attempt." | By the rule above. |
| Block | Moves it to Blocked equipment and keeps refusing it: "`<name>` is blocked. The station will keep refusing this certificate." | By the rule above. |
| Discard all pending certificates (on the group head) | Asks "Discard the certificate waiting for review?" or "Discard the N certificates waiting for review?" ("Nothing is approved or blocked by this: the requests are removed and the list makes room again. Equipment the Connector dials after this appears here as a new request."), with **Discard** and **Keep the list**. | By the rule above. |

The list holds at most 100 certificates. While it is full, a further certificate stays refused but is not retained, and the card says so: "The review list below is full. While it is, a new certificate is refused without being added here, so the equipment you are waiting for may never appear. Discard the certificates waiting for review to make room.", with the count of refusals since it filled once there are any. Every such refusal is journaled.

## Approved equipment {#approved-equipment}

"Certificates the Connector may open sessions with.", with the count. Each row shows a neutral dot, the claimed name, "Claimed equipment identity · Approved by `<user>` on `<date and time>`" (or "at this station"), the fingerprint, and a details disclosure with Address, Subject, Issuer, Application URI, Valid until and Last seen. With none: "No equipment certificate approved."

| Command | What it does | Greyed when (situation) |
| --- | --- | --- |
| Import certificate (on the group head) | Opens a file picker for the equipment's public certificate (`.der`, `.cer`, `.crt` or `.pem`, up to 64 KB) and approves it before the first connection: "`<name>` is approved from `<file>`. Check the fingerprint below against the one in the equipment's documentation." A larger file: "`<file>` is larger than an equipment certificate. Import the public certificate file (.der, .cer or .pem), not an archive." | By the rule above. |
| Withdraw approval (on the row, danger ink) | Asks "Withdraw approval for `<name>`?": "The current session with this equipment is closed and the station stops reading from it. The certificate returns to the review list, so the next connection asks you again.", with **Withdraw** and **Keep approved**. Then: "Approval withdrawn for `<name>`. Its session was closed and it is waiting for review again." | By the rule above. |

The hint under the head: "Have the equipment's public certificate already? Import it here to approve it before the first connection, instead of letting the connection fail once. Check the fingerprint it adds against the one in the equipment's documentation." Equipment usually ships with its certificate, which is why this side has the import first. Importing a blocked certificate lifts the block. Withdrawing sends the certificate back to review, not to a block: you asked to be asked again.

## Blocked equipment {#blocked-equipment}

A collapsed disclosure, "Blocked equipment" with the count, drawn only while at least one exists. Each row shows a red dot, the claimed name, "Claimed equipment identity · Blocked by `<user>` on `<date and time>`", the fingerprint, and **Unblock**, which returns it to the review list without approving it: "`<name>` is unblocked and has returned to the review list." A blocked certificate never returns on its own.

## Where the decisions live {#where-the-decisions-live}

The equipment stores sit under `ua\pki\southbound` in the station's data root (`pending`, `trusted`, `blocked` and the SDK's `rejected`), with the address each certificate was seen at, attempt counts and decisions in `equipment-access.json`. They are separate from the inbound stores, so an equipment certificate can never become permission for an application to connect to the station's own server, nor appear as an inbound request. They are not part of a configuration [backup](settings-backups).

## What this section does not do {#what-this-section-does-not-do}

Nothing is approved automatically, and no setting turns that off. The card does not configure the device itself (address, credentials and polling are on the [Connector](connector-devices)), does not show the equipment's live values, and does not decide about applications dialing this station, which is [Client access](settings-opcua-client-access).