Introduction

The YubiHSM 2 is a USB-based, multi-purpose cryptographic device for servers. Its diminutive physical size is ideal for installation directly into internal or external server ports. It is a Hardware Security Module (HSM) that is cost-effective for all organizations. It provides advanced cryptography including hashing, asymmetric, and symmetric key cryptography to protect the cryptographic keys that secure critical applications, identities, and sensitive data in an enterprise for certificate authorities, databases, code signing and more.

Operating System Requirements

The YubiHSM 2 SDK is built and provided for the following operating systems. This includes Windows, Linux distributions, and macOS. See YubiHSM2 Releases for most recent platform YubiHSM2 downloads.

Operating System	Architecture	Latest Date	Version
Centos	amd64	2023-11-02	Centos7
Darwin	amd64	2025-08-11	macOS 15, 14, 13
Darwin	arm64	2025-08-11	macOS 15, 14, 13
Darwin	universal	2025-08-11	macOS 15, 14, 13
Debian	amd64	2025-06-12	Debian 12, 11
Fedora	amd64	2025-06-12	Fedora 42, 41
Ubuntu	amd64	2025-06-12	Ubuntu 25.04, 24.10, 24.04
Windows	amd64	2025-06-12	Windows Server 2025, 2022, Windows 11, 10

YubiHSM 2 Device Specifications

Physical Characteristics

YubiHSM 2 Physical Device

Form factor: nano designed for confined spaces such as internal USB ports in servers
Dimensions: 12mm x 13mm x 3.1mm
Weight: 0.5g

Temperatures

Operational range: 0°C - 40°C (32°F - 104°F)
Storage range: -20°C - 85°C (-4°F - 185°F)

Host Interface

Universal Serial Bus (USB-A) 1.x Full Speed (12 Mbit/s) Peripheral with bulk interface.

Storage Capacity

All data stored as objects. 256 object slots, 126KB max total
Stores up to 127 rsa2048 or 93 rsa3072 or 68 rsa4096 or 255 of any elliptic curve type, assuming only one authentication key is present
Objects: Authentication keys (used to establish sessions); Asymmetric private keys; Opaque binary data objects (e.g. x509 certificates); Wrap keys; HMAC keys

YubiHSM 2 Cryptographic Specifications

Cryptographic Interfaces

PKCS#11 API version 2.40
Yubico Key Storage Provider (KSP) to access Microsoft CNG. The KSP is provided as 64-bit and 32-bit DLLs
Full access to device capabilities through Yubico’s YubiHSM Core Libraries (C, Python)

Advanced Encryption Standard (AES)

128, 192, and 256-bit keys
Support for Electronic Code Book (ECB), Cipher Block Chaining (CBC) and Counter (CCM) modes

RSA

2048-, 3072-, and 4096-bit keys (with e=65537)
Signing using PKCS#1v1.5 and PSS
Decryption using PKCS#1v1.5 and OAEP

Elliptic Curve Cryptography (ECC)

Curves: secp224r1, secp256r1, secp256k1, secp384r1, secp521r, bp256r1, bp384r1, bp512r1, Ed25519
Signing: ECDSA (all except Ed25519), EdDSA (Ed25519 only)
Derivation: ECDH (all except Ed25519)

Hashing Functions

SHA-1, SHA-256, SHA-384, SHA-512

Key Wrap

Import and export using NIST-approved AES-CCM Wrap with 128-, 196-, and 256-bit keys

Random Numbers

On-chip True Random Number Generator (TRNG) used to seed NIST SP 800-90A Rev.1 AES-256 CTR_DRBG

Attestation

Asymmetric key pairs generated on-device may be attested using a device-specific Yubico attestation key and certificate, or using your own keys and certificates imported into the HSM.

Attestation

Asymmetric keys in the YubiHSM can be attested by another Asymmetric key. The attestation process creates a new x509 certificate for the attested key.

The device comes pre-loaded with an attestation key and certificate referenced by ID 0. It is possible to use your own key and certificate for attestation, these then must have the same ID and the key has to have the sign-attestation-certificate Capability set.

Details

Serial is a random 16 byte integer
Issuer is the subject of the attesting certificate
Dates is copied from the attesting certificate
Subject is the string YubiHSM Attestation id 0x with the attested ID appended
If the attesting key is RSA the signature is SHA256-PKCS#1v1.5
If the attesting key is EC the signature is ECDSA-SHA256

Certificate Extensions

Some certificate extensions are added in the generated certificate and/or the pre-loaded certificate:

OID	Description	Data Type	Generated/Pre-loaded
1.3.6.1.4.1.41482.4.1	Firmware version	Octet String	Both
1.3.6.1.4.1.41482.4.2	Serial number	Integer	Both
1.3.6.1.4.1.41482.4.3	Origin	Bit String	Generated
1.3.6.1.4.1.41482.4.4	Domains	Bit String	Generated
1.3.6.1.4.1.41482.4.5	Capabilities	Bit String	Generated
1.3.6.1.4.1.41482.4.6	Object ID	Integer	Generated
1.3.6.1.4.1.41482.4.9	Label	Utf8String	Generated
1.3.6.1.4.1.41482.4.10	FIPS certified	Integer	Pre-loaded
1.3.6.1.4.1.41482.4.12	FIPS certified	Boolean	Generated

Pre-Loaded Certificates

The pre-loaded certificate can be fetched as an opaque object with ID 0. This will in turn be signed by an intermediate CA which is signed by a Yubico root CA.

Intermediates

E45DA5F361B091B30D8F2C6FA040DB6FEF57918E.pem

FIPS certified

Note

This section applies to YubiHSM 2 FIPS devices only.

YubiHSM 2 FIPS is FIPS 140-2 Level 3 certified device, which means it can be used in solutions that are meant to comply with FIPS 140-2 requirements. Certification by National Institute of Standards and Technology (NIST) can be found at: https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/3916

YubiHSM 2 FIPS devices include the text “FIPS” laser-etched onto the surface of the device and allow YubiHSM 2 FIPS to run in FIPS Approved mode.

The YubiHSM 2 is available in a FIPS-capable version called YubiHSM 2 FIPS.

The YubiHSM 2 FIPS can be configured in an approved mode and a non-approved mode of operation. In the approved mode, only FIPS-approved algorithms are supported. In the non-approved mode, additional non-approved algorithms such as rsa-pkcs1-sha1 are supported.

FIPS-approved mode can be configured only after a device reset by enabling the fips-mode option and immediately changing the default Authentication key.

For instructions on configuring the YubiHSM 2 FIPS in FIPS-approved mode, see FIPS Mode Support Guide.

A key attestation generated on a YubiHSM 2 FIPS device with firmware version 2.4.1 or newer has an X.509 extension present with OID 1.3.6.1.4.1.41482.4.12. If the key attestation was generated in FIPS-approved mode, this extension BOOLEAN value is TRUE. Otherwise, the BOOLEAN value is FALSE.

The pre-loaded certificate of a YubiHSM 2 FIPS device has an X.509 extension present with OID 1.3.6.1.4.1.41482.4.10. This extension has an INTEGER value encoding its FIPS certificate. Currently, the value 6 refers to the YubiHSM 2 FIPS certificate for firmware version 2.2.

Performance

Performance varies depending on usage. The accompanying Software Development Kit includes performance tools that can be used for additional measurements. Example metrics from an otherwise unoccupied YubiHSM 2:

RSA-2048-PKCS1-SHA256: ~139ms
RSA-3072-PKCS1-SHA384: ~504ms
RSA-4096-PKCS1-SHA512: ~852ms
ECDSA-P224-SHA1: ~64ms
ECDSA-P256-SHA256: ~73ms
ECDSA-P384-SHA384: ~120ms
ECDSA-P521-SHA512: ~210ms
EdDSA-25519-32Bytes: ~105ms
EdDSA-25519-64Bytes: ~121ms
EdDSA-25519-128Bytes: ~137ms
EdDSA-25519-256Bytes: ~168ms
EdDSA-25519-512Bytes: ~229ms
EdDSA-25519-1024Bytes: ~353ms
AES-(128|192|256)-CCM-Wrap: ~10ms
HMAC-SHA-(1|256): ~4ms
HMAC-SHA-(384|512): ~243ms

Management

Mutual authentication and secure channel between applications and the YubiHSM 2.
M of N unwrap key restore via YubiHSM Setup Tool

Core Concepts

Key Element Relationships

Relationship between Objects capabilities, authentication keys capabilities, and domains. This is required knowledge to be successful with operating the HSM.

Production Use

For production, requires more advanced and nuanced permissions.

Testing Use

For quick and dirty (but less secure) activities, can skip the permissions. This is if you are using it only for yourself in your testing sandbox.

Objects

The first concept that we will present is the Object. Any persistently stored and self-contained piece of information present in a YubiHSM 2 is an Object. This is intentionally a very generic and broad definition which can be easily rephrased as everything is an Object. Objects have associated properties that characterize them and give them different meanings. Regardless of the kind and the specific properties, any YubiHSM 2 device can store up to 256 Objects. Their combined size cannot exceed 126 KB.

Object Type

To identify what an Object can and cannot do, we define an attribute called Object Type, or simply Type. A Type is not enough to uniquely identify an Object, but it defines the set of operations that can be performed with or on it. The following types are defined:

Name	Value	yubihsm-shell name
Opaque Object	0x01	opaque
Authentication Key Object	0x02	authentication-key
Asymmetric Key Object	0x03	asymmetric-key
Wrap Key Object	0x04	wrap-key
HMAC Key Object	0x05	hmac-key
Template Object	0x06	template
OTP AEAD Key Object	0x07	otp-aead-key
Symmetric Key Object	0x08	symmetric-key
Public Wrap Key Object	0x09	public-wrap-key

Authentication Key Object

An Authentication Key is one of the most fundamental Objects there are. Authentication Keys can be used to establish a Session with a device. See Create and Authenticate a Session. An Authentication Key is basically two long-lived AES keys: an encryption key and a MAC key. When establishing a Session, the long-lived keys are used to generate three session keys:

An encryption key used to encrypt the messages exchanged with the device
A MAC key used to create an authentication tag for each message sent to the device
A response MAC key used to create an authentication tag for each response message sent by the device

The session keys are temporary and are destroyed when the Session is no longer in use.

Asymmetric Key Object

An Asymmetric Key Object is what the YubiHSM 2 uses to represent an asymmetric key-pair where only the private key can be used to perform cryptographic operations.

HMAC Key Object

An HMAC Key is a secret key used when computing and verifying HMAC signatures.

Opaque Object

An Opaque Object is an unchecked kind of Object, normally used to store raw data in the device. No specific restrictions (besides size limitations) are imposed to this type of Object.

OTP AEAD Key Object

An OTP AEAD Key Object is a secret key used to decrypt Yubico OTP values for further verification by a validation process.

Public Wrap Key Object

A Public Wrap Key Object is an RSA public key used to wrap Objects and (a)symmetric keys during the export process.

Symmetric Key Object

Available with firmware version 2.3.1 or later.

A Symmetric Key Object is a secret key used when encrypting and decrypting AES.

Object Types are encoded as an 8-bit value.

Template Object

A Template Object is a binary template used for example to validate SSH certificate requests.

Wrap Key Object

A Wrap Key Object is a secret key used to wrap and unwrap Objects during the export and import process.

Object Types are encoded as an 8-bit value.

Capabilities

A Capability is an attribute that can be given to an Objects allowing specific operations to be performed on or with it. Commands like digital signature generation and data decryption require (and check) for a predetermined set of Capabilities to be present on an Object. Further below is the list of existing Capabilities.

It is important to know that there are no restrictions on which Capabilities can be set on an Object. Specifically, this means that it is possible to assign meaningless Capabilities to Objects that will never be able to use them, for example it is possible to have an Asymmetric Object with the Capability verify-hmac. Such a Capability only makes sense for HMAC Key objects, but the device allows defining a superset. Lack of Capabilities required for a specific operation causes a command requiring that Capability to fail.

Delegated Capabilities

Every Object stored on the device has an associated set of Capabilities. There is a second set of so-called Delegated Capabilities that only Authentication Keys and Wrap Keys have. This is used to capture the indirection that Authentication Keys and Wrap Keys can be used as a means of storing more Objects on a device. In both cases Delegated Capabilities are used as a filter.

For Authentication Keys, Delegated Capabilities define the set of Capabilities that can be set or “bestowed” onto an Object created by the Authentication Key. Any operation attempting to create Objects with a Capability outside of this set fails.

For Wrap Keys, Delegated Capabilities define the set of Capabilities that an Object can have when imported or exported using the Wrap Key. A larger set of Capabilities causes the import operation to fail.

Capability Protocol Details

A Set of Capabilities is an 8-byte value. Each Capability is identified by a specific bit, as shown in the Hex Mask column below.

Name	Hex Mask	Applicable Objects	Description
—————————Asymmetric Keys——————————–
delete-asymmetric -key	0x0000020000000000	authentication -key	Delete Asymmetric Key Objects
generate-asymmetric -key	0x0000000000000010	authentication -key	Generate Asymmetric Key Objects
put-asymmetric-key	0x0000000000000008	authentication -key	Write Asymmetric Key Objects
—————————Authentication Keys—————————-
delete-authen- tication-key	0x0000010000000000	authentication -key	Delete Authentication Key Objects
put-authentication -key	0x0000000000000004	authentication -key	Write Authentication Key Objects
change- authentication-key	0x0000400000000000	authentication -key	Replace Authentication Key Objects
——————————–Certificate——————————-
sign-attestation- certificate	0x0000000400000000	authentication -key, asymmetric-key	Attest properties of Asymmetric Key Objects
sign-ssh-certificate	0x0000000002000000	authentication -key, asymmetric-key	Sign SSH certificates
———————————–Data———————————–
decrypt-cbc	0x0010000000000000	authentication -key, symmetric-key	Decrypt data using AES CBC mode. Available with firmware version 2.3.1 or later.
decrypt-ecb	0x0004000000000000	authentication -key, symmetric-key	Decrypt data using AES ECB mode. Available with firmware version 2.3.1 or later.
decrypt-oaep	0x0000000000000400	authentication -key, asymmetric-key	Decrypt data using RSA-OAEP
decrypt-pkcs	0x0000000000000200	authentication -key, asymmetric-key	Decrypt data using RSA-PKCS1v1.5
encrypt-cbc	0x0020000000000000	authentication -key, symmetric-key	Encrypt data using AES CBC mode. Available with firmware version 2.3.1 or later.
encrypt-ecb	0x0008000000000000	authentication -key, symmetric-key	Encrypt data using AES ECB mode. Available with firmware version 2.3.1 or later.
———————————–ECDH———————————–
derive-ecdh	0x0000000000000800	authentication -key, asymmetric-key	Perform ECDH
———————————–Global———————————
get-option	0x0000000000040000	authentication -key	Read device- global options
set-option	0x0000000000020000	authentication -key	Write device- global options
———————————–HMAC———————————–
delete-hmac-key	0x0000080000000000	authentication -key	Delete HMAC Key Objects
generate-hmac-key	0x0000000000200000	authentication -key	Generate HMAC Key Objects
put-mac-key	0x0000000000100000	authentication -key	Write HMAC Key Objects
sign-hmac	0x0000000000400000	authentication -key, hmac-key	Compute HMAC of data
verify-hmac	0x0000000000800000	authentication -key, hmac-key	Verify HMAC of data
—————————————Log——————————–
get-log-entries	0x0000000001000000	authentication -key	Read the Log Store
———————————–Opaque———————————
delete-opaque	0x0000008000000000	authentication -key	Delete Opaque Objects
get-opaque	0x0000000000000001	authentication -key	Read Opaque Objects
put-opaque	0x0000000000000002	authentication -key	Write Opaque Objects
———————————–OTP————————————
create-otp-aead	0x0000000040000000	authentication -key, otp-aead-key	Create OTP AEAD
decrypt-otp	0x0000000020000000	authentication -key, otp-aead-key	Decrypt OTP
delete-otp-aead-key	0x0000200000000000	authentication -key	Delete OTP AEAD Key Objects
generate-otp-aead -key	0x0000001000000000	authentication -key	Generate OTP AEAD Key Objects
put-otp-aead-key	0x0000000800000000	authentication -key	Write OTP AEAD Key Objects
randomize-otp-aead	0x0000000080000000	authentication -key, otp-aead-key	Create OTP AEAD from random data
rewrap-from-otp- aead-key	0x0000000100000000	authentication -key, otp-aead-key	Rewrap AEADs from one OTP AEAD Key Object to another
rewrap-to-otp- aead-key	0x0000000200000000	authentication -key, otp-aead-key	Rewrap AEADs to one OTP AEAD Key Object from another
———————————–Random———————————
get-pseudo-random	0x0000000000080000	authentication -key	Extract random bytes
————————————–Reset——————————-
reset-device	0x0000000010000000	authentication -key	Perform a factory reset on the device
———————————–Signatures—————————–
sign-ecdsa	0x0000000000000080	authentication -key, asymmetric-key	Compute digital signatures using ECDSA
sign-eddsa	0x0000000000000100	authentication -key, asymmetric-key	Compute digital signatures using EDDSA
sign-pkcs	0x0000000000000020	authentication -key, asymmetric-key	Compute signatures using RSA- PKCS1v1.5
sign-pss	0x0000000000000040	authentication -key, asymmetric-key	Compute digital signatures using using RSA-PSS
———————————–Template——————————-
delete-template	0x0000100000000000	authentication -key	Delete Template Objects
get-template	0x0000000004000000	authentication -key	Read Template Objects
put-template	0x0000000008000000	authentication -key	Write Template Objects
———————————–Wrap ———————————-
delete-wrap-key	0x0000040000000000	authentication -key	Delete Wrap Key Objects
export-wrapped	0x0000000000001000	authentication -key, wrap-key	Export other Objects under wrap
exportable-under -wrap	0x0000000000010000	all	Mark an Object as exportable under wrap
generate-wrap-key	0x0000000000008000	authentication -key	Generate Wrap Key Objects
import-wrapped	0x0000000000002000	authentication -key, wrap-key	Import wrapped Objects
put-wrap-key	0x0000000000004000	authentication -key	Write Wrap Key Objects
unwrap-data	0x0000004000000000	authentication -key, wrap-key	Unwrap user- provided data
wrap-data	0x0000002000000000	authentication -key, wrap-key	Wrap user- provided data
—————————–Public Key Wrap —————————–
put-public-wrap -key	0x0040000000000000	authentication -key, wrap-key	Write RSA Public Wrap Key
delete-public-wrap -key	0x0080000000000000	authentication -key, wrap-key	Delete RSA Public Wrap Key
——————————Symmetric Keys —————————–
generate-symmetric -key	0x0001000000000000	authentication -key	Generate AES key. Available with firmware version 2.3.1 or later.
put-symmetric-key	0x0000800000000000	authentication -key	Import AES key. Available with firmware version 2.3.1 or later.
delete-symmetric-key	0x0002000000000000	authentication -key	Delete AES key. Available with firmware version 2.3.1 or later.

Domains

A Domain is a logical partition that can be conceptually mapped to a container. In a YubiHSM 2 there are 16 independent Domains; an Object can belong to one or more Domains.

Note

Authentication Keys are Objects and thus can belong to multiple Domains.

Domains serve as a means to secure Objects so that they cannot be addressed by independent applications running on the same device. This is achieved by specifying the Object’s Domain. Only users or applications that belong to the same Domain as an Object can access it or use it.

The details involved in accessing an Object are explained in the Effective Capabilities (Tying It All Together) page.

Domain Protocol Details

Domains are encoded as 16-bit values, where each Domain is represented by a bit

Domain Number	Hex Mask
1	0x0001
2	0x0002
3	0x0004
4	0x0008
5	0x0010
6	0x0020
7	0x0040
8	0x0080
9	0x0100
10	0x0200
11	0x0400
12	0x0800
13	0x1000
14	0x2000
15	0x4000
16	0x8000

Label

A Label is a sequence of bytes that can be used to add a mnemonic reference to Objects.

Label Protocol Details

Labels are 40 bytes long. As far as the YubiHSM is concerned, the label is only a string of raw bytes and is not restricted to printable characters or valid UTF-8 glyphs.

Object ID

The ID property is used to identify an Object of a given Type. This means that to uniquely identify an Object stored on a YubiHSM 2, the couple (Type, ID) is required. There can be more than one Object with a given ID and more than one Object with a given Type, but only one Object with a specific ID and Type. This is so that logical connections between Objects can be established by giving a set of connected Objects of different Types the same ID.

An Object ID can have values in the range [0-65535] or [0x0000-0xffff] in hexadecimal. Note that this range is larger than the maximum number of Objects that can be stored in the device (256). Regardless of the type, ID 0x0000 and 0xffff are reserved for internal Objects.

Object ID Protocol Details

Object IDs are encoded as 16-bit values.

Origin

The Origin is a one-byte value that is part of the metadata associated with an asymmetric key object. The origin indicates whether the asymmetric key was generated on a YubiHSM 2 device or generated externally and subsequently imported. If a key was imported, the origin also indicates whether the key was imported in plaintext or using a wrap key.

Origins are also used when generating a key attestation. The attestation certificate will contain the key’s origin as an X.509 extension. See Attestation.

Origin Protocol Details

Origins are encoded as 8-bit values, where each defined origin is represented by a bit according to the following table:

Name	Hex Mask
generated	0x0001
imported	0x0002
imported_wrapped	0x0010

Note that not all combinations of these bits are valid. In practice, only the combinations 0x0001, 0x0002, and 0x0011, 0x0012 can occur.

Sequence

The Sequence is a one-byte value that is part of the metadata associated with an Object. The Sequence describes how many times an Object with a given ID and Type has been written. This is mostly useful for caching to determine if new data needs to be fetched from the device.

Sequence Protocol Details

Sequence is 8 bits long and will wrap.

Effective Capabilities (Tying It All Together)

This document describes how Object-related concepts interact with each another.

Let us assume that we are establishing a Session with Authentication Key 0xabcd so that the Session can use the Asymmetric Key 0x1234 to sign some data. We are assuming that Asymmetric Key 0x1234 is an RSA 2048-bit key and that we would like to generate a signature using RSASSA-PSS.

Create and Authenticate a Session

Creating and authenticating a Session requires knowledge of what the long-lived keys are (or what the associated derivation password is).

When a valid Session is established, certain properties of the Authentication Key used to create the Session are inherited by the Session itself. These are:

The Domain(s) to which the Authentication Key belongs (for more information, see Domains),
The Capabilities of the Authentication Key (see Capabilities) and
The Delegated Capabilities (see Capabilities) associated with Authentication Key 0xabcd .

The Session’s inherited properties serve to ensure that the only Objects stored in the HSM 2 that we can see and access are those that belong to the same Domain(s) as Authentication Key 0xabcd.

Generate a Signature

The required capability must be set on both the Authentication Key used to establish the Session (Authentication Key 0xabcd) and the target Object used to perform the operation (Asymmetric Key 0x1234).

Assuming that Asymmetric Key 0x1234 is in one such Domain, we can now continue and ask the HSM 2 to generate a signature. To do so we will send the Sign Data command over the Session. It will not execute successfully unless the arguments of the command are valid, i.e., no malformed data can be sent to the device or an error will occur.

Both Authentication Key 0xabcd and Asymmetric Key 0x1234 must have the Capability sign-pss set.

Effective Capabilities and Role Definition

The overlap between

The Capabilities of the Authentication Key used to establish the Session and
The Capabilities of the target Object involved in the operation

defines the Effective Capabilities. An operation on a given target Object over a given Session can succeed only if the Capabilities required by the operation are included in the Effective Capabilities.

The interaction between Domains and Effective Capabilities enables flexible setup and role definition. For example,

It is possible to assign a set of Capabilities to an Object, and then distribute those Capabilities across different Authentication Keys so that each key is enabled to perform only a single operation on the target Object, and no key performs the same operation as any other key.
Similarly, it is possible to disable specified operations by not assigning the requisite Capabilities to an Authentication Key. For example, an “Administrator” Authentication Key could be enabled only to create keys while a “User” Authentication Key could be enabled only to use those same keys.

Workflow

Determine which Objects will have operations performed on them
Determine which Authentication Keys you will use
Determine which operations will be performed
Use a spreadsheet (if necessary) to map out the interaction between the first three items
With the aid of the spreadsheet, create domains to enable the interaction.

Note

Authentication Keys are Objects and thus can belong to multiple Domains.
You could construct your domains:
- per operation - put an Object and an Authentication Key into each domain, or
- per Object - put the Authentication Key(s) for all the operations to be performed on each Object into a single domain
- per Authentication Key - put the requisite Object(s) into each Domain.
For example, if you wanted Jan to do the signing and Ola to do the importing, you could adopt any of the above options, but the Effective Capabilities enable you to assign far more complex webs of responsibilities.
Use the spreadsheet to set the Capabilities and Delegated Capabilities appropriately, “appropriateness” being determined by the Objects and operations to be performed on them.

Guides for Supported Platforms and Protocols

For each of the listed platforms and protocols, see the linked content for configuration and usage.

Most commonly used

Require additional configuration