Device Bootstrapping with TLS
TLS support is optional for KNX IoT devices. The onboarding flow described in this document applies only to TLS-capable devices. Constrained devices that do not support TLS use the OSCORE-only onboarding flow (see Device Bootstrapping).
This document describes the commissioning workflow when a Management and
Commissioning Client (MaC) commissions a KNX IoT device using TLS
encrypt-only mode for transport encryption (certificate verification
inactive). After establishing the secure channel and installing the tool
key, the MaC enrolls a new LDevID signed by its Domain CA. The preferred
method is CSR-based enrollment (/auth/sen or /a/sen), where the device generates
its own key pair and the private key never leaves the device.
For constrained devices that lack sufficient entropy or processing power
for local key generation, the MaC can use Server-Side Key Generation
(SKG) (/auth/skg) as a fallback. SKG generates the key pair
externally and pushes both the private key and the signed LDevID to the
device.
This example extends the OSCORE-only commissioning flow described in Device Bootstrapping by adding TLS transport encryption and CSR-based LDevID enrollment. A 3rd-party KNX IoT Vertical Integration (HEMS, BMS, edge gateways) can use the same flow. It may omit the enrollment step if it does not need to replace the device's LDevID.
Overview
| Phase | Description | Transport | Endpoints |
|---|---|---|---|
| Step 1 | Device Information Acquisition | Out-of-band (barcode scan) | — |
| Step 2 | Provide credentials to MaC | Manual / API | — |
| Step 3 | Secure Device Onboarding + LDevID Enrollment | CoAP-over-TLS (encrypt-only) + PASE | /.well-known/knx/spake, /auth/at, /auth/crts, /auth/sen (or /a/sen or /auth/skg) |
| Step 4 | Runtime Interworking | CoAP-over-TLS (mutual TLS) | /.well-known/core, /f/*, /p/*, /k |
Preconditions
- The KNX IoT device is in default configuration state (factory reset).
- The device has an IDevID (manufacturer device certificate) or a pre-installed self-signed LDevID.
- The device is reachable on the IP network (Ethernet, Wi-Fi, or Thread with border router).
- The MaC has a Domain CA key pair (can sign new LDevID certificates).
- The MaC has the device's KNX Serial Number and password (from barcode).
TLS Mode: Encrypt-Only
In encrypt-only mode, the TLS connection provides transport encryption and forward secrecy without certificate verification. Neither the client nor the server validates the peer's certificate. This mode is appropriate for onboarding because:
- PASE (SPAKE2+) provides mutual authentication: the MaC proves knowledge of the password, and the device proves knowledge of its verifier.
- The TLS layer adds forward secrecy (ephemeral ECDHE key exchange).
- Certificate validation is not yet possible: the device's trust list is empty in default configuration state, and the MaC's Domain CA is unknown to the device.
After onboarding, the MaC installs its Domain CA certificate in the device
trust list (/auth/crts) and enrolls a new LDevID. Subsequent TLS
sessions can then use mutual TLS for full certificate validation.
LDevID Certificate Examples
The MaC uses two certificates at different phases of the commissioning lifecycle. This section shows both.
Self-Signed Certificate (Onboarding)
During onboarding (Steps 3.2–3.6), the device presents its self-signed LDevID for the TLS encrypt-only connection. The MaC does not send a client certificate. Neither side validates the peer's certificate, it serves only for the ECDHE key exchange. The certificate follows the LDevID subject naming conventions so it can serve as a baseline for later CA signing. This stage requires no CA infrastructure.
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: ecdsa-with-SHA256
Issuer:
O = Siemens AG
CN = knx-00fd10f1f253
Validity:
Not Before: Jan 1 00:00:00 2025 GMT
Not After : Dec 31 23:59:59 9999 GMT
Subject:
O = Siemens AG
CN = OCT110
serialNumber = 00fd10f1f253
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
ASN1 OID: prime256v1 (secp256r1 / NIST P-256)
pub:
04:c1:d2:e3:f4:05:16:27:38:49:5a:6b:7c:8d:9e:
af:b0:c1:d2:e3:f4:05:16:27:38:49:5a:6b:7c:8d:
9e:af:b0:c1:d2:e3:f4:05:16:27:38:49:5a:6b:7c:
8d:9e:af:b0:c1:d2:e3:f4:05:16:27:38:49:5a:6b:
7c:8d:9e:af:b0
X509v3 extensions:
X509v3 Basic Constraints: critical
CA: FALSE
Signature Algorithm: ecdsa-with-SHA256
30:44:02:20:00:... (DER-encoded ECDSA signature)
SHA-256 Fingerprint:
a3:4b:7c:91:d2:e8:f0:15:26:37:48:59:6a:7b:8c:9d:
ae:bf:c0:d1:e2:f3:04:15:26:37:48:59:6a:7b:8c:9d
This certificate has no SAN URI, no Key Usage, and no Extended Key Usage
extensions because the device does not validate it during encrypt-only
onboarding (verify_mode = CERT_NONE). Authentication comes from PASE,
not from this certificate.
Device LDevID (Runtime)
After onboarding, the device obtains a new LDevID signed by the MaC's
Domain CA. With CSR-based enrollment, the device generates the key pair
locally and submits a CSR via /auth/sen. This
certificate replaces the device's IDevID for runtime mutual TLS authentication.
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 4096 (0x1000)
Signature Algorithm: ecdsa-with-SHA256
Issuer:
O = KNXA
CN = DomainCA-33a3
Validity:
Not Before: Jan 1 00:00:00 2025 GMT
Not After : Dec 31 23:59:59 9999 GMT
Subject:
O = Siemens AG
CN = OCT110
serialNumber = 00fd10f1f253
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
ASN1 OID: prime256v1 (secp256r1 / NIST P-256)
pub:
04:a1:b2:c3:d4:e5:f6:07:18:29:3a:4b:5c:6d:7e:
8f:90:a1:b2:c3:d4:e5:f6:07:18:29:3a:4b:5c:6d:
7e:8f:90:a1:b2:c3:d4:e5:f6:07:18:29:3a:4b:5c:
6d:7e:8f:90:a1:b2:c3:d4:e5:f6:07:18:29:3a:4b:
5c:6d:7e:8f:90
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 Subject Alternative Name:
URI: knx://ia.33a3.20a
X509v3 Basic Constraints: critical
CA: FALSE
Signature Algorithm: ecdsa-with-SHA256
30:45:02:21:00:... (DER-encoded ECDSA signature)
SHA-256 Fingerprint:
b5:2e:8f:a1:c3:d4:e6:07:19:2a:3b:4c:5d:6e:7f:80:
91:a2:b3:c4:d5:e6:f7:08:19:2a:3b:4c:5d:6e:7f:80
Note
The self-signed certificate is not validated during onboarding
(encrypt-only). The runtime LDevID SAN URI SHALL match the sub claim
(CBOR key 2) in the access token, and the serialNumber SHALL contain
the KNX Serial Number from the IDevID.
Step 1: Device Information Acquisition
The process begins by scanning the device's barcode (DMC or QR code) to obtain:
| Data | Source | Example |
|---|---|---|
| KNX Serial Number | QR / DMC barcode | 00fd10f1f253 |
| Password (authentication code) | QR / DMC barcode | LJFYEARVK56STM70 |
The KNX Serial Number uniquely identifies the device and is also embedded in
the LDevID subject field (serialNumber=00fd10f1f253). The password is the
SPAKE2+ proof-of-possession for the PASE handshake.
Step 2: Provide Device Information to MaC
The operator transfers the serial number and password to the MaC through:
- Manual entry in the MaC configuration UI
- API call from a barcode scanner application
- Import from a project configuration file
The MaC now has the minimal credentials needed for onboarding: the serial number (for discovery) and the password (for PASE authentication).
Step 3: Secure Device Onboarding
Protocol Sequence
MaC (Management Client) KNX IoT Device (has IDevID or LDevID)
| |
| ~~~~ Step 3.1: Device Discovery ~~~~ |
| |
|--- [mDNS] _knx._udp.local SN query ----->| DNS-SD discovery by serial
|<-- [mDNS] SN=00fd10f1f253 host:port -----|
| |
| ~~~~ Step 3.2: TLS Connection ~~~~ |
| |
|==== TLS 1.2+ Handshake (ENCRYPT_ONLY) ==>| No cert verification
|==== ClientHello (no client cert) =======>|
|<=== ServerHello (device presents IDevID) | (accepted without validation)
|<=========== TLS Established ============>| Encrypted channel active
| |
| ~~~~ Step 3.3: PASE over TLS ~~~~ |
| |
| ┌-------- PASE --------┐ |
| │ │ |
| │ ┌-- SPAKE2+ --┐ │ |
|--- [CON] POST /.well-known/knx/spake --->| Step 1: Parameter Request
|<-- [CON] 2.04 Changed -------------------| Step 1: Parameter Response
|--- [CON] POST /.well-known/knx/spake --->| Step 2: Credential Request
|<-- [CON] 2.04 Changed -------------------| Step 2: Credential Response
|--- [CON] POST /.well-known/knx/spake --->| Step 3: Verification
|<-- [CON] 2.04 Changed -------------------| Step 3: Verified
| │ └-------------┘ │ |
| │ │ |
| ~~~~ Step 3.4: Domain CA + Tool Key ~~~~|
| │ │ |
|--- [CON] POST /auth/crts --------------->| Push Domain CA certificate
|<-- [ACK] 2.01 Created -------------------| (trust anchor for LDevID)
| │ │ |
|--- [CON] POST /auth/at ----------------->| Install tool key
|<-- [ACK] 2.01 Created -------------------|
| │ │ |
| ~~~~ Step 3.5: Enroll LDevID (CSR) ~~~~ |
| │ │ |
| [Device has or generates key pair] |
| │ │ |
|--- [CON] GET /auth/sen ----------------->| Read CSR from device
| [Device creates PKCS#10 CSR] │ |
|<-- [ACK] 2.05 Content (PKCS#10 CSR) -----|
| │ │ |
| [MaC signs CSR with Domain CA] │ |
| │ │ |
|--- [CON] POST /auth/sen ---------------->| Push signed LDevID cert
|<-- [ACK] 2.01 Created -------------------| (signed by Domain CA)
| │ │ |
| ~~~~ Step 3.6: Delete PASE Key ~~~~ |
| │ │ |
|--- [CON] DELETE /auth/at/<kid> --------->| Remove temporary key
|<-- [ACK] 2.02 Deleted -------------------|
| │ │ |
| └----------------------┘ |
| |
| ~~~~ Step 3.7: Configure Runtime ~~~~ |
| |
|--- [CON] POST /auth/at ----------------->| Install runtime access token
|<-- [ACK] 2.01 Created -------------------| (scope: if.d, if.o, if.p)
| |
Step 3.1: Device Discovery
The MaC discovers the device via DNS-SD (mDNS) using the KNX serial
number as a subtype. The MaC browses for
_00fd10f1f253._sub._knx._udp.local and resolves the resulting
PTR → SRV → AAAA chain.
; Step 1: Browse by serial number subtype
Query: PTR _00fd10f1f253._sub._knx._udp.local
Answer: PTR 00fd10f1f253._knx._udp.local
; Step 2: Resolve service instance
Query: SRV 00fd10f1f253._knx._udp.local
Answer: SRV 0 0 5684 knx-00fd10f1f253.local
; Step 3: Resolve hostname to address
Query: AAAA knx-00fd10f1f253.local
Answer: AAAA fe80::1a:2b:3c:4d
In practice, mDNS responders often include additional records in the
answer section so that all three steps resolve in a single exchange.
Port 5684 is the standard CoAP-over-TLS port. If the device advertises
port 5683 (plain CoAP/UDP), the MaC connects to port 5684 for TLS
transport and the URI scheme changes from coap:// to coaps+tcp://.
Step 3.2: TLS Connection (Encrypt-Only)
The MaC opens a TLS connection using encrypt-only mode:
URI: coaps+tcp://[fe80::1a:2b:3c:4d]:5684
SSLContext configuration:
protocol = TLS_CLIENT
minimum_version = TLSv1_2
check_hostname = False (encrypt-only: no verification)
verify_mode = CERT_NONE (encrypt-only: accept any certificate)
ALPN = ["coap"] (RFC 8323)
The TLS handshake uses ephemeral ECDHE for key exchange, providing forward secrecy. The device presents its IDevID or LDevID certificate during the handshake, but the MaC does not validate it (encrypt-only mode). The MaC does not send a client certificate.
At this point, the channel has encryption but no authentication. Authentication comes from PASE in the next step. Once PASE succeeds, the MaC has proven knowledge of the password and the device has proven knowledge of its verifier, establishing trust in the encrypted session.
Step 3.3: PASE (SPAKE2+ Handshake)
PASE runs over the encrypted TLS channel, providing mutual authentication. SPAKE2+ is an augmented PAKE: the MaC (client) holds the password, while the device (server) holds only a verifier derived from the password, for example, during manufacturing. The device never knows the actual password. The protocol is identical to the OSCORE-only bootstrapping flow (see Device Bootstrapping), but now benefits from TLS forward secrecy as an additional security layer. After SPAKE2+, a temporary OSCORE context is active.
The SPAKE2+ handshake on /.well-known/knx/spake produces:
K_shared(32 bytes): temporary OSCORE master secret- Mutual authentication: the MaC proved it knows the password, the device proved it knows the verifier
Step 3.4: Install Domain CA + Tool Key
With the temporary OSCORE context active, the MaC sends OSCORE-protected CoAP messages inside the TLS channel (double encryption: TLS at transport, OSCORE at application layer). The MaC first installs its Domain CA certificate in the device trust list, then installs the tool key.
Access Token Format and Scope
See Device Access Control for the full access token CBOR structure, credential types (OSCORE and X.509), and scope definitions.
The following example shows a tool key that uses the coap_tls profile,
which means the MaC also has an LDevID (signed by its Domain CA). This is
an alternative to using an OSCORE-based tool key (coap_oscore profile).
1. Push Domain CA certificate (POST /auth/crts):
POST coaps+tcp://[<IPv6>]:5684/auth/crts
Content-Format: application/pkix-cert (287)
Payload: <DER-encoded Domain CA certificate>
Response: 2.01 Created
The MaC must install the Domain CA first because the tool key's cnf claim
references the CA certificate in the trust list (/auth/crts/1). This also
establishes the trust anchor for the new LDevID enrolled in Step 3.5.
Note
The device trust list SHALL support at least 3 CA certificates.
Only a MaC with if.sec scope can configure the trust list.
2. Install tool key (CBOR, POST /auth/at):
Since both the MaC and the device support TLS, the tool key uses the
coap_tls profile with an X.509 certificate reference.
[{
0: "mac-tk", // kid: tool key identifier
2: "knx://ia.33a3.10a", // sub: matches MaC LDevID SAN URI
8: { // cnf (confirmation)
3: h'b52e8fa1c3d4e607192a3b4c5d6e7f8091a2b3c4d5e6f708192a3b4c5d6e7f80' // thumbprint reference to X.509
},
9: ["if.c", "if.p", "if.d", "if.sec", "if.swu"], // scope: admin access
38: 254 // profile = coap_tls
}]
With coap_tls profile (38: 254), the cnf claim references the MaC's
CA certificate in the device trust list (installed just before). The
MaC's LDevID SAN must match the sub claim in the access token.
Step 3.5: Enroll LDevID (CSR-Based)
The device uses an existing or newly generated key pair and creates
a PKCS#10 Certificate Signing Request (CSR). The MaC retrieves the CSR with
GET /auth/sen, signs it with its Domain CA, and pushes the new LDevID
certificate back with POST /auth/sen. The private key never leaves the
device, which is the preferred enrollment method for devices with
sufficient entropy and processing power.
The payload format follows EST-CoAPS [RFC 9148] clause 4.2 (simple enrollment).
1. Read CSR from device (GET /auth/sen):
GET coaps+tcp://[<IPv6>]:5684/auth/sen
Response: 2.05 Content
Content-Format: application/multipart-core
Payload: <PKCS#10 CSR>
2. Push signed LDevID certificate (POST /auth/sen):
POST coaps+tcp://[<IPv6>]:5684/auth/sen
Content-Format: application/multipart-core
Payload: <DER-encoded X.509 LDevID certificate>
Response: 2.01 Created
Note
The POST /auth/sen request does not require the PASE session.
A MaC with sufficient access rights (tool key with if.sec scope) can
push a signed LDevID certificate at any time.
After successful enrollment:
- The device uses the new LDevID for (D)TLS server authentication.
- The device uses its locally generated private key for TLS handshake signatures.
- The previous IDevID (or old LDevID) is no longer used for runtime TLS.
- On device factory reset, the device deletes the LDevID and private key and reactivates the default X.509 certificates.
Step 3.5a (Alternative): Server-Side Key Generation (SKG)
For constrained devices that lack sufficient entropy or processing power for
local key generation, the MaC uses SKG instead of Step 3.5. The MaC
generates a key pair, signs the LDevID certificate with its Domain CA,
and pushes both the private key and the LDevID certificate to the
device via /auth/skg.
The payload format follows EST-CoAPS [RFC 9148] clause 5.3 (server-side key generation).
POST coaps+tcp://[<IPv6>]:5684/auth/skg
Content-Format: application/multipart-core
Payload: <private key (PKCS#8)> + <LDevID certificate (DER-encoded X.509)>
Response: 2.01 Created
SKG transmits the device's private key over the network. TLS protects the channel with encryption and forward secrecy, making this acceptable for constrained devices. Prefer CSR-based enrollment (Step 3.5) whenever the device supports local key generation.
Step 3.6: Delete PASE Key
The PASE access token cannot authorize its own deletion. The MaC opens a new TLS session, authenticates with the tool key from Step 3.4, and deletes the temporary PASE access token:
DELETE /auth/at/rkey
After deletion, the temporary OSCORE context becomes invalid. All subsequent communication uses the tool key credentials.
Step 3.7: Configure Runtime Access Token (Mutual TLS)
The MaC installs a runtime access token for application data access. This token grants read access to diagnostics, output group objects, and parameters. After installing runtime access tokens, the MaC proceeds with configuration download (Function Point Tables and parameters) as described in Device Bootstrapping—Configuration Download.
Because the runtime token uses coap_tls profile (38: 254), the device
verifies the MaC's TLS client certificate with the Domain CA in its trust
list. This makes runtime communication mutual TLS (mTLS): both sides
authenticate via X.509 certificates signed by the same Domain CA.
MaC Certificate: Onboarding vs. Runtime
The MaC uses two different certificates during the commissioning lifecycle:
| Phase | MaC Certificate | Verification | Purpose |
|---|---|---|---|
| Onboarding (Steps 3.2–3.6) | None (not sent) | N/A | TLS encryption only; SPAKE2+ provides authentication |
| Runtime (Step 4) | LDevID signed by Domain CA | Device verifies with trust list | Mutual TLS authentication |
During onboarding, the MaC does not send a client certificate because TLS operates in encrypt-only mode. Authentication relies on SPAKE2+, which provides mutual proof of identity through the shared password. Additionally, if the device presents a manufacturer-signed IDevID during the TLS handshake, the MaC can verify it to confirm device authenticity before starting SPAKE2+.
For runtime mTLS, the MaC needs an LDevID signed by the Domain CA that it
installed in the device trust list (Step 3.4). The MaC's LDevID SAN URI
shall match the sub claim in both the tool key and runtime access tokens.
The SAN URI can use either IA-based identity (knx://ia.{iid_hex}.{ia_hex})
or serial-based identity (knx://sn.{serial}).
Device Certificate: Before and After Enrollment
The device's TLS certificate changes during commissioning:
| Phase | Device Certificate | Signed by | Used for |
|---|---|---|---|
| Before enrollment | IDevID or self-signed LDevID | Manufacturer CA or device | TLS server auth during onboarding (not verified by default) |
| After enrollment (Step 3.5) | LDevID (operational certificate) | MaC's Domain CA | TLS server auth at runtime (verified by MaC) |
If the device presents a manufacturer-signed IDevID, the MaC can optionally verify it to confirm device genuineness before proceeding with PASE. This requires the MaC to have the manufacturer's CA certificate.
The MaC's Domain CA must sign the enrolled LDevID, matching the CA
in the device trust list. This creates a mutual trust relationship.
Each side verifies the peer's certificate chain with its trust anchor
(Domain CA). Each side also confirms the SAN URI matches the access
token sub claim.
Runtime Access Token (CBOR, POST /auth/at):
[{
0: "client-rt", // kid: runtime token identifier
2: "knx://ia.33a3.10a", // sub: matches MaC LDevID SAN URI
8: { // cnf (confirmation)
3: h'b52e8fa1c3d4e607192a3b4c5d6e7f8091a2b3c4d5e6f708192a3b4c5d6e7f80' // thumbprint reference to X.509
},
9: ["if.d", "if.o", "if.p"], // scope: read diagnostics + outputs + params
38: 254 // profile = coap_tls
}]
The runtime token uses coap_tls profile (38: 254) with the same Domain CA
reference as the tool key. The MaC authenticates via its LDevID certificate,
verified with the Domain CA in the device trust list. For group communication
(multicast), OSCORE (profile 2) is still required because TLS is
point-to-point only.
Step 4: Runtime Interworking
With onboarding complete and the new LDevID installed, a runtime Client
connects using mutual TLS. The MaC configured this client's access token
in Step 3.7. Both sides present Domain CA-signed certificates: the device
presents its enrolled LDevID, and the Client presents its own LDevID.
Each side verifies the peer's certificate chain with the configured trust
anchor (Domain CA). Each side also confirms that the certificate's SAN URI
matches the sub claim in the corresponding access token.
Client (Runtime) KNX IoT Device (new LDevID)
| |
|===== TLS Connect (MUTUAL TLS) ==========>|
|---- Client presents LDevID ------------->| Device verifies vs. Domain CA
|<--- Device presents LDevID --------------| Client verifies vs. Domain CA
|<=========== mTLS Established ===========>| Both sides authenticated
| |
| ~~~~ Read Datapoint ~~~~ |
| |
|--- GET /p/temperature ------------------>| Read sensor value
|<-- 2.05 Content {1: 21.5} ---------------|
| |
|--- GET /p/temperature?m ---------------->| Read with metadata
|<-- 2.05 Content (value + dpt + unit) ----|
| |
Read a Datapoint
Value only:
GET coaps+tcp://[<IPv6>]:5684/p/temperature
Response (application/cbor):
{1: 21.5} // 1 = value key
With metadata:
GET coaps+tcp://[<IPv6>]:5684/p/temperature?m
Response (application/cbor):
{
1: 21.5, // value
"id": "knx://sn.00fd10f1f253/p/temperature",
"dpt": ":dpt.temp",
"dpa": ":dpa.321.51",
"unit": "DEG_C",
"min": 0,
"max": 40,
"cov": 0.5,
"hbt": 900,
"if": ["if.d", "if.o"]
}
Cybersecurity Considerations
Defense in Depth
The encrypt-only TLS + PASE combination provides two independent security layers:
| Layer | Mechanism | Provides |
|---|---|---|
| Transport | TLS 1.2+ (ECDHE key exchange) | Forward secrecy, encryption |
| Application | PASE (SPAKE2+) | Mutual authentication, OSCORE key derivation |
Upgrading to Mutual TLS
The MaC installed its Domain CA in the device trust list (Step 3.4) and
enrolled a new LDevID (Step 3.5). The device can now verify the MaC's
certificate. For full mutual TLS, the MaC also needs to trust the Domain CA
and confirm the device's SAN URI matches the access token sub claim:
MaC SSLContext for mutual TLS:
protocol = TLS_CLIENT
minimum_version = TLSv1_2
check_hostname = True (mutual TLS: verify device identity)
verify_mode = CERT_REQUIRED
load_verify_locations(Domain CA certificate)
ALPN = ["coap"] (RFC 8323)
The device presents its new LDevID (signed by the Domain CA) and the MaC
verifies the certificate chain, enabling TLSMode.MUTUAL.
When to Use Encrypt-Only vs. Mutual TLS
| Scenario | TLS Mode | Rationale |
|---|---|---|
| Initial onboarding (default state) | ENCRYPT_ONLY | Trust list empty; PASE provides authentication |
| MaC commissioning with LDevID enrollment | ENCRYPT_ONLY → MUTUAL | Encrypt-only for PASE; mutual TLS after enrollment |
| KNX IoT Router integration | MUTUAL | Both peers have LDevID; bidirectional trust, no OSCORE required |
| 3rd party vertical integration | MUTUAL | Both peers have LDevID; bidirectional trust, no OSCORE required |