# Add devices and manage access safely

Manage device identities and secure access profiles for Opia workflows.

> Applies to Opia 26.8.1.

Devices are the managed network assets Opia connects to. Each enabled device needs a management address and an appropriate credential profile before Opia can run connectivity, backup or collection workflows.

## Add a device

![Add Device dialog with Device tab selected, name and hostname fields, Enabled checked and an unset management endpoint.](/assets/images/screenshots/application/add-device.png)

*Add Device on the Device tab, showing identity fields and the Enabled choice before a management address is entered. The displayed values are illustrative. Open full-size screenshot*

1. Open Devices and select Add Device.
1. Enter a clear display name and the management IP address or resolvable hostname.
1. Select the Cisco platform/driver context shown by the editor.
1. Assign a credential profile and, if useful, site, tag or role information.
1. Save the device, select it and run Test Connection.

A new device provisionally consumes one Managed Network Unit until trusted fingerprint or inventory evidence verifies its physical chassis or present stack membership.

## Import multiple devices

1. Select Create Import Template and populate a copy of the template.
1. Select Import Devices.
1. Review the preview carefully. Opia reports invalid addresses, missing credential matches, duplicates and capacity problems.
1. Commit only the rows you expect to add.

Import files contain device information, not passwords or private-key contents. Use export for inventory exchange and review, not as a credential backup.

## Create a credential profile

![Credential profile dialog with name, username, SSH password or private key selection, and blank password and enable-secret fields.](/assets/images/screenshots/application/credential-profile.png)

*Credential profile dialog with authentication choices and blank secret fields. The displayed account is an illustrative example. Open full-size screenshot*

Credential profiles allow multiple devices to use the same authorised access identity without storing plaintext secrets in the operational database.

| Method | Use | Customer guidance |
| --- | --- | --- |
| Password | Username and password | Use a dedicated, least-privilege network account with the read permissions required by the selected workflows. |
| Private key | Username, key and optional passphrase | Import the key through Opia and retain your own approved backup of the original key. |
| Enable mode | Enable secret | Add only where the target device requires privilege escalation for the commands Opia needs. |

Opia protects stored secrets through the Agent. Saved passwords are not displayed back to users, and private-key contents are not exported.

## Test connectivity and review SSH host keys

![Edit Device dialog on the Access tab with management IP, SSH port, credential profile and Requires enable mode selected.](/assets/images/screenshots/application/edit-device-access.png)

*Edit Device, Access tab, showing the selected device's management endpoint, credential profile and enable-mode choice. The values are illustrative, not recommended defaults. Open full-size screenshot*

**Test Connection** checks whether Opia can reach and authenticate to the selected device. Common failures include DNS or routing problems, TCP/22 filtering, incorrect credentials, unreadable key material, insufficient enable privilege, prompt-detection problems or an SSH host-key mismatch.

On first use, Opia can record a new SSH host key under its configured trust-on-first-use policy. If the host key later changes, review the exact algorithm and fingerprint through an independent trusted channel before accepting it.

## Device status

![Devices list with ACCESS-SW1 selected and its Overview inspector showing device health and summary.](/assets/images/screenshots/application/devices-overview.png)

*Illustrative device list with ACCESS-SW1 selected. The Overview inspector shows its health and summary; inventory is shown as missing in this example. Open full-size screenshot*

A device can be disabled, online, unreachable, stale or in a warning state. A successful ping alone does not prove that SSH authentication and command collection will work. Fingerprinting can improve device identity using platform, serial and other collected evidence.