Device Identity
Every NetDefense device has its own cryptographic identity — a unique private key generated on the device itself the first time the NDAgent starts. The key never leaves the device. NetDefense only ever sees the matching public half.
This identity is what makes the channel between NetDefense and your firewall trustworthy. The TLS connection protects traffic in transit, but device signing goes further: every command coming from NetDefense is cryptographically signed, and every response coming back from your firewall is signed too. That means a stolen credential or an intercepted connection alone isn’t enough to forge instructions in either direction.
What gets signed
Section titled “What gets signed”Two pieces of the conversation between NetDefense and your device carry signatures:
-
Commands sent to the device. When you trigger a sync, open a remote-access session, or run any task, NetDefense signs the instruction before sending it. The agent on your firewall verifies that signature against NetDefense’s published public key before acting on the command. An unsigned or invalid command is dropped silently and never executed.
-
Responses sent back to NetDefense. When the agent reports the result of a sync, a ping, or any other task, it signs the response with its own device key. NetDefense verifies the signature against the device’s public key on file before trusting the result. A response that doesn’t verify is rejected and the task is marked failed.
What it protects against
Section titled “What it protects against”Without device signing, the network connection’s authentication boundary is “anyone with a valid token can speak as the org.” With device signing, the boundary tightens to “only this specific device, holding this specific key, can speak as itself.”
Concretely, signing closes these scenarios:
-
A leaked organization token. The org token authenticates the connection, not the device. With signing, an attacker who steals the token still can’t impersonate any of your devices — they don’t have the device’s private key. Tasks they submit go nowhere; responses they fabricate are rejected.
-
Tampered commands in the network path. A man-in-the-middle who manages to intercept the channel can’t inject new commands or modify the ones already in flight. Any change invalidates the signature.
-
Forged status reports. A compromised intermediary can’t tell NetDefense “the sync succeeded” on behalf of your firewall. Only the device, with its own key, can produce a verifiable response.
The signature also leaves an audit trail. Every signed task and signed response is preserved end-to-end, so if there’s ever a question about who did what, the cryptographic record stands on its own.
When the key changes
Section titled “When the key changes”The same key sticks with the device for its entire lifetime. There are only two situations where it changes:
- First install. The agent generates the key the first time it starts. It’s persisted to disk and re-used on every subsequent run.
- Re-binding. If you need to rotate the device’s identity — a suspected leak, hardware replacement, or a fresh OPNsense install — you initiate a re-bind ceremony. The agent generates a new key and registers the new public half with NetDefense. The old key is discarded.
Re-binding is the only operator-driven action involving the device key. Everything else is invisible.
What survives a software upgrade
Section titled “What survives a software upgrade”Because the device key is the device’s identity, NetDefense is careful to preserve it across NDAgent version upgrades. Running pkg upgrade os-netdefense (or the per-environment variant) keeps the key file intact — same key, same identity, same registration on the NetDefense side. No re-bind needed for a routine upgrade.
A re-bind is required only if you do something that wipes the key file (a full reinstall from scratch, restoring the firewall from a backup that predates the key, or moving the device to a different hardware unit).