> For the complete documentation index, see [llms.txt](https://eaclouddoc.eauditor.eu/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://eaclouddoc.eauditor.eu/eacloud-docs-en/features/data-loss-prevention/triggers/device-connection.md).

# Device Connection

Trigger **Device connection** is used to control selected classes of hardware devices on computers covered by the DLP policy.

It allows you to specify whether devices belonging to a given group should be:

* ignored by the policy,
* always allowed,
* always blocked.

In this way, you can control Bluetooth devices, CD-ROM drives, keyboards, mice, imaging devices, and other supported Windows device classes.

{% hint style="info" %}
A rule can contain only **one trigger**, but in the trigger **Device connection** you can configure multiple device groups at the same time. You can also add multiple actions and multiple notifications to a rule.
{% endhint %}

{% hint style="warning" %}
Trigger **Device connection** is not used for detailed management of specific USB storage devices.

If you want to identify specific USB flash drives, e.g. based on Device ID, or distinguish between encrypted and unencrypted media, use the trigger [**USB device connection**](/eacloud-docs-en/features/data-loss-prevention/triggers/usb-device-connection.md).
{% endhint %}

### How does device control work?

For each supported device group, you can independently define how the policy behaves.

Three settings are available:

| Setting          | Behavior                                                         |
| ---------------- | ---------------------------------------------------------------- |
| **Ignore**       | The policy does not enforce a setting for the given device group |
| **Always allow** | Devices belonging to the group remain allowed                    |
| **Always block** | Devices belonging to the group are blocked                       |

<figure><img src="https://3262380731-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fdzip3GyvGq5q5J3qckWN%2Fuploads%2Fsa5LhmspFc89g3FMwZAp%2Fimage.png?alt=media&amp;token=c2f60ed6-9c2a-4c37-8f96-50e186950023" alt="Konfiguracja wyzwalacza Podłączenie urządzenia w eAuditor Cloud z listą grup urządzeń oraz ustawieniami Ignoruj, Zawsze dopuszczaj i Zawsze blokuj." width="375"><figcaption><p><em>For each device group, you can independently define how the policy behaves.</em></p></figcaption></figure>

### Available device states

#### Ignore

Setting **Ignore** means that the DLP policy does not enforce any state for the selected device group.

In that case:

* the system does not enforce blocking or allowing the device,
* the user or a local administrator can change the device state in Windows,
* connecting a device belonging to this group does not trigger this part of the rule.

Use this setting for device groups you do not want to control using the policy.

#### Always allow

Setting **Always allow** causes devices belonging to the selected group to remain available.

In that case:

* devices from the given group can be used,
* attempts to locally block this group are blocked by eAgent and logged,
* the policy enforces a state that allows the devices to be used.

Example:

If the policy is to block selected device classes, but keyboards and mice should always remain available, set for them **Always allow**.

#### Always block

Setting **Always block** causes devices belonging to the specified group to be blocked.

In that case:

* devices belonging to the group are blocked,
* local attempts to unblock the devices are blocked,
* attempts to change the enforced setting may be logged,
* actions and notifications configured in the rule can be triggered if the rule is violated.

{% hint style="warning" %}
Before applying the setting **Always block** carefully check the selected device category. Blocking the wrong class may limit access to equipment the user needs to work.
{% endhint %}

### Supported device groups

The trigger uses device groups corresponding to hardware classes supported by Windows.

Among the available groups are:

| Device group                      | Example use                                                                        |
| --------------------------------- | ---------------------------------------------------------------------------------- |
| **Storage volume backups**        | Mechanisms related to volume backups and snapshots                                 |
| **Battery devices**               | Batteries and power controllers                                                    |
| **Biometric devices**             | Fingerprint readers, face recognition, and other biometric devices                 |
| **Bluetooth devices**             | Devices communicating via Bluetooth                                                |
| **CD-ROM drives**                 | Optical drives                                                                     |
| **Display adapters**              | Devices responsible for image output                                               |
| **Floppy disk drives**            | Floppy disk drives                                                                 |
| **Global Positioning System**     | GPS devices and modules                                                            |
| **Hard disk controllers**         | Controllers responsible for communication with disks                               |
| **Human Interface Devices (HID)** | Input and control devices, e.g. keyboards, mice, joysticks                         |
| **IEEE 1284.4 compliant devices** | Devices using a standard used, among other things, for communication with printers |
| **IEEE 1394 host bus controller** | FireWire interface controllers                                                     |
| **Imaging devices**               | Cameras, scanners, and cameras                                                     |
| **IrDA devices**                  | Devices using infrared communication                                               |
| **Keyboards**                     | Keyboard devices                                                                   |
| **Removable media**               | Supported devices related to removable media                                       |
| **Modems**                        | Devices used for data transmission                                                 |
| **Mouse**                         | Pointing devices                                                                   |
| **Multifunction devices**         | Devices combining multiple functions, e.g. printing and scanning                   |
| **Multimedia**                    | Devices and components responsible for audio and video handling                    |

{% hint style="info" %}
Group names are derived from the device classification used by Windows. Therefore, some categories may be more technical than the device name used in everyday language.
{% endhint %}

### Trigger configuration

{% stepper %}
{% step %}

#### Open the rule

Create a new rule or open an existing rule for editing.
{% endstep %}

{% step %}

#### Select a trigger

In the **Triggers** select:

**Device connection**

Because a rule can contain only one trigger, selecting this mechanism defines the main type of event controlled by the rule.
{% endstep %}

{% step %}

#### Find the device group

In the list, find the device group you want to control.

You can configure several different groups within the same trigger.
{% endstep %}

{% step %}

#### Set the behavior

For each required group, select the appropriate state:

* **Ignore**,
* **Always allow**,
* **Always block**.

Leave the groups you do not want to control as **Ignore**.

<div align="left"><figure><img src="https://3262380731-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fdzip3GyvGq5q5J3qckWN%2Fuploads%2Fsa5LhmspFc89g3FMwZAp%2Fimage.png?alt=media&amp;token=c2f60ed6-9c2a-4c37-8f96-50e186950023" alt="Lista klas urządzeń w wyzwalaczu Podłączenie urządzenia z różnymi stanami kontroli przypisanymi do poszczególnych grup." width="375"><figcaption><p><em>Each device group can have its behavior defined independently.</em></p></figcaption></figure></div>
{% endstep %}

{% step %}

#### Configure actions

If violating the device setting should cause an additional response, go to the section [**Actions**](/eacloud-docs-en/features/data-loss-prevention/actions.md).

You can assign more than one action to the same rule.
{% endstep %}

{% step %}

#### Configure notifications

If the administrator or another recipient should be notified about the event, add the appropriate notifications.

You can assign multiple notifications to a rule.
{% endstep %}

{% step %}

#### Save the rule

After completing the configuration, save the rule and assign it to the appropriate policy.
{% endstep %}

{% step %}

#### Update policies

Click:

**Update policies**

so that the latest configuration is deployed to the eAgents.
{% endstep %}
{% endstepper %}

### Example use case

#### Blocking selected device classes on the production floor

Assume that the following should not be used on computers located on the production floor:

* Bluetooth devices,
* CD-ROM drives.

At the same time, the remaining device classes should not be affected by this rule.

#### Configuration

Create a rule with the trigger:

**Device connection**

Then set:

| Group                 | Setting      |
| --------------------- | ------------ |
| **Bluetooth devices** | Always block |
| **CD-ROM drives**     | Always block |
| Remaining groups      | Ignore       |

<figure><img src="https://3262380731-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fdzip3GyvGq5q5J3qckWN%2Fuploads%2FUC27owCWDxNTCcE8iEfS%2Fimage.png?alt=media&amp;token=a2e6e780-e324-4585-81ce-a8b4cd58b741" alt="Przykład konfiguracji wyzwalacza Podłączenie urządzenia blokującego urządzenia Bluetooth i napędy CD-ROM." width="238"><figcaption><p><em>Example of a policy blocking selected device classes.</em></p></figcaption></figure>

After the policy is deployed to the eAgents, the specified device classes will be blocked on computers covered by the policy.

### Device connection and USB device connection

These two triggers address different issues.

| Function                                    | Device connection | USB device connection          |
| ------------------------------------------- | ----------------- | ------------------------------ |
| Control of entire device classes            | Yes               | It is not the primary use case |
| Printers, Bluetooth, CD-ROM, HID, etc.      | Yes               | No                             |
| Control of a specific USB flash drive       | No                | Yes                            |
| Identification based on Device ID           | No                | Yes                            |
| Distinguishing specific USB storage devices | No                | Yes                            |
| Control of encrypted and unencrypted media  | No                | Yes                            |

{% hint style="info" %}
If you want to answer the question **"can devices of this type be used?"**, usually choose **Device connection**.

If the question is **"which specific USB storage devices can be used?"**, go to the trigger **USB device connection**.
{% endhint %}

### Testing the rule

{% stepper %}
{% step %}

#### Use a test computer

First, assign the policy to a device on which you can safely verify the configuration behavior.
{% endstep %}

{% step %}

#### Update policies

Deploy the new configuration to the eAgent using the option **Update policies**.
{% endstep %}

{% step %}

#### Connect a device

Connect a device belonging to the controlled group.

For example, for the category **Bluetooth devices** verify the behavior of the appropriate Bluetooth device.
{% endstep %}

{% step %}

#### Check the result

Verify that the device behaves according to the setting:

* **Ignore**,
* **Always allow**,
* **Always block**.
  {% endstep %}

{% step %}

#### Check additional responses

If the rule contains actions or notifications, also verify that they were executed according to the configuration.
{% endstep %}
{% endstepper %}

{% hint style="warning" %}
When testing the blocking of input devices, exercise particular caution. Incorrect configuration of groups such as keyboards, mice, or HID can make it difficult for the user to operate the computer.
{% endhint %}

### FAQ

<details>

<summary><strong>Is the Device connection trigger used to block USB flash drives?</strong></summary>

It is not intended for detailed control of specific USB storage devices.

To manage USB flash drives based on their properties, e.g. Device ID, use the trigger [**USB device connection**](/eacloud-docs-en/features/data-loss-prevention/triggers/usb-device-connection.md).

</details>

<details>

<summary><strong>Can I control several device types in one rule?</strong></summary>

Yes.

The rule uses one trigger **Device connection**, but in its configuration you can define settings for multiple device groups.

</details>

<details>

<summary><strong>What does Ignore mean?</strong></summary>

The system does not enforce a state for the given device group. The group is neither allowed nor blocked by this part of the policy enforcement.

</details>

<details>

<summary><strong>What is the difference between Ignore and Always allow?</strong></summary>

**Ignore** leaves the device state outside the control of this rule.

**Always allow** actively enforces the ability to use devices belonging to the given group while preventing local blocking of the devices.

</details>

<details>

<summary><strong>Can the user locally unblock a group set to Always block?</strong></summary>

No. The setting **Always block** is intended to enforce blocking of devices belonging to the specified group.

</details>

<details>

<summary><strong>Can I change the setting for a given group later?</strong></summary>

Yes. Open the rule for editing, change the group state, and save the configuration.

After making the change, remember to use the option **Update policies**.

</details>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://eaclouddoc.eauditor.eu/eacloud-docs-en/features/data-loss-prevention/triggers/device-connection.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.