Bootstrapping Remote Security Key Infrastructure (BRSKI) automates trusted onboarding of new devices into a network using vouchers, an enrolment workflow, and a manufacturer root of trust. It helps prevent rogue devices from joining unchecked. Administrators should protect voucher issuance, verify enrolment authorities, and watch for unauthorised device claims or failed attestations.
How BRSKI establishes trust before a device is admitted
BRSKI is not just a secure join process, it is a trust-establishment workflow. The device begins with a manufacturer-backed identity, then uses a voucher to prove it is entitled to join a specific network, and then hands off to an enrolment authority that can issue operational credentials. That sequence matters because trust is created in stages, not assumed at first contact.
The voucher is the binding element between the device and the intended network. It prevents a generic device from presenting itself as eligible, and it lets the onboarding system distinguish a legitimate claim from an unauthorised one. In practice, the real security value comes from the chain of trust, manufacturer root, voucher, and enrolment authority, all agreeing on the same device.
For a Device and IoT Identity Guide-style deployment, BRSKI is the point where device identity becomes operationally usable. It turns a trusted manufacturing identity into a network-accepted identity, which is why attestation and device provenance are part of the security story, not optional extras.
What the voucher and enrolment steps actually do
The voucher gives the joining device a cryptographic path into the target network without relying on shared default passwords or manual provisioning. The device presents the voucher during onboarding, the registrar or enrolment workflow validates it, and the network can then establish a secure relationship with the device. The workflow reduces human error and lowers the chance that an unauthenticated or cloned device will be accepted.
Enrolment is where the device moves from being recognised as a manufactured asset to being a managed participant in the local environment. Once the trust anchor is verified, the enrolment authority can issue the credentials or certificates that the network will accept for ongoing access. That is why BRSKI is usually discussed alongside lifecycle management rather than just initial access.
Because the process depends on proof of origin and entitlement, it overlaps with certificate-based Machine Identity, PKI and Certificate Lifecycle Guide concerns. The onboarding event is only the beginning, and the operational identity still needs lifecycle control after the first successful join.
Where BRSKI reduces exposure, and where it can still fail
BRSKI reduces the risk that rogue, cloned, or misissued devices can join a network unnoticed, but it does not remove the need to secure the onboarding authority itself. If voucher issuance is weak, if enrolment approval is sloppy, or if the trust anchor is mismanaged, the workflow can be abused at scale. The control is strong only when every step in the trust chain is tightly governed.
That is why administrators should treat onboarding logs, voucher creation, and enrolment decisions as security-sensitive events. A device that repeatedly fails attestation, requests re-enrolment unexpectedly, or claims an identity outside its expected manufacturing context may be signalling misconfiguration or active abuse. Those patterns belong in monitoring, not in a support queue.
Remote enrolment also depends on the surrounding access path. In environments that expose device onboarding across untrusted links, the network and identity controls around the entry point matter as much as the protocol itself. For that reason, BRSKI is often best understood alongside the protections described in a Remote Access Identity Guide, especially where onboarding happens over third-party or branch connectivity.
Risk and Threat Considerations
BRSKI’s main security risk is not that the protocol is weak in the abstract, but that its trust inputs can be manipulated. If a voucher is stolen, replayed, or issued to the wrong device, the attacker may gain a legitimate-looking path into the network. If attestation is weak, the environment may accept a device that is not the one the manufacturer vouched for.
Failure mechanism: Attackers target the issuance or validation step, then exploit the fact that onboarding systems often trust cryptographic evidence more than human review. A compromised voucher workflow, a forged claim about device provenance, or a poorly controlled enrolment authority can convert a secure join process into a trusted entry path for the wrong device.
Impact: The result can be unauthorised device admission, persistence through legitimate credentials, and loss of trust in the device inventory. At scale, that creates a hidden foothold problem, because the device is not merely present, it is present with network-sanctioned identity.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Non-Organizational Users) | BRSKI governs device onboarding and machine authentication to a network. |
| IA-5 — Authenticator Management | BRSKI relies on vouchers, certificates, and credential lifecycle control during enrolment. | |
| AC-6 — Least Privilege | Newly onboarded devices should receive only the access needed after trust is established. | |
| Recommendation — Apply IA-9 to verify device identity before granting operational access. Manage onboarding credentials with issuance, rotation, and revocation controls. Limit enrolled devices to the minimum permissions needed for their role. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | BRSKI fits a verify-before-trust onboarding model for devices joining a network. |
| Recommendation — Require continuous verification before any device is trusted on the network. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | BRSKI depends on strong device authentication during onboarding and attestation. |
| NHI-07 — Long-Lived Secrets | BRSKI onboarding and post-enrolment identity should avoid static credentials that outlive need. | |
| Recommendation — Use strong device authentication so only legitimate devices can enrol. Shorten credential lifetime and rotate secrets used in device onboarding. | ||
Practitioner Guidance
What to verify: Confirm who can issue vouchers, who can approve enrolment, and what evidence is retained for each onboarding event. The key question is whether every accepted device can be tied back to a known manufacturer identity, an intended deployment, and an accountable approval path.
What to prioritise: Treat failed attestation, unexpected re-enrolment, and mismatched device claims as investigation triggers. Those are the signals that the join process may be being probed, replayed, or misused, and they should be reviewed before assuming the device is benign.
Practitioner takeaway: BRSKI works best when onboarding is treated as a controlled identity transition, not a one-time connectivity event. The protocol gives you a strong trust framework, but only disciplined voucher governance, attestation review, and enrolment oversight keep that trust from being abused.
Related resources from NHI Mgmt Group
- Bootstrapping Remote Security Key Infrastructure (BRSKI)
- How should security teams reduce OT remote access risk without blocking maintenance work?
- How should security teams reduce remote-work identity risk for employees using home offices?
- How should security teams secure hybrid and remote work without adding too much user friction?