Pre-shared keys create fragile lifecycle management. They are often deployed once, never rotated, and tied to devices that are expensive to replace or reach physically. When a key is compromised, the blast radius is broad because the same secret may persist across many endpoints. That makes revocation, renewal, and accountability far weaker than with per-device certificates.
Why pre-shared keys fail as an operational security model
Pre-shared keys work when the environment is small, static, and tightly controlled. They fail when the device population grows, when replacement is expensive, or when the same secret has to survive long deployment cycles. The core problem is not encryption strength, but the weakness of a shared secret as a lifecycle and accountability mechanism.
Once a key is baked into many devices, security becomes dependent on perfect protection of every copy. That is a fragile assumption for low-power equipment that may be hard to reach, hard to inventory, or hard to patch consistently.
What breaks in the key lifecycle and trust model
What breaks first is rotation. A pre-shared key often stays in place because changing it means touching every affected endpoint, coordinating downtime, and risking outage on devices that cannot be managed like normal servers. When renewal is expensive, organisations delay it until the key effectively becomes permanent.
Accountability also breaks. A shared secret cannot easily tell you which device used it, whether a credential was copied, or whether one compromised endpoint is the source of broader abuse. That makes incident response slower and makes revocation coarse-grained, because the only safe action may be to replace the secret everywhere.
The trust model weakens further when the same credential is reused across a fleet, because compromise of one endpoint can become compromise of many. This is why device identity guidance increasingly favours unique credentials and device certificates over fleet-wide shared secrets; Device and IoT Identity Guide covers that transition in practical terms.
What low-power systems need instead of shared secrets
The better model is per-device identity with revocation, renewal, and onboarding that can scale without a technician visiting every unit. For constrained devices, that usually means a unique certificate or equivalent asymmetric credential, plus a lifecycle process that can replace one device’s trust material without tearing down the rest of the fleet.
That shift also changes how the system is operated. Security teams need to think less about a single protected secret and more about issuance, expiry, attestation, enrollment, and recovery paths. If the environment cannot support those controls today, the design should at least isolate secrets by device or by small trust domain rather than by entire population.
For API-style machine authentication, the same principle applies: replace long-lived shared secrets with stronger, revocable credentials where possible. API Key Management Guide is useful here because it frames rotation, scoping, and revocation as lifecycle requirements, not optional hygiene.
Risk and Threat Considerations
Shared keys create a high-blast-radius compromise pattern. If one low-power device is captured, the attacker may inherit a credential that authenticates many devices, which turns a local compromise into fleet-wide exposure and makes detection harder because the secret itself provides no device-level distinction.
Failure mechanism: A single copied secret can be reused across endpoints, so revocation becomes all-or-nothing and the organisation loses the ability to isolate one compromised device without disrupting the rest of the fleet.
Impact: Attackers can impersonate legitimate devices, persist longer than expected, and force expensive field replacement or mass rekeying after compromise.
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 surface, NIST SP 800-53 Rev 5, NIST SP 800-63 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Shared keys need rotation, revocation, and lifecycle control. |
| IA-9 — Service Identification and Authentication | Device-to-device or device-to-service secrets are machine authentication. | |
| AC-6 — Least Privilege | Fleet-wide secrets often grant broader access than one device needs. | |
| Recommendation — Manage device secrets with expiry, rotation, and revocation controls. Use strong non-shared authenticators for device-to-service access. Scope each device credential to the minimum necessary access. | ||
| OWASP Non-Human Identity Top 10 | NHI-07 — Long-Lived Secrets | Pre-shared keys become risky when they persist across long device lifecycles. |
| NHI-05 — Overprivileged NHI | Shared keys often authorize more devices or actions than intended. | |
| NHI-01 — Improper Offboarding | Revoking one compromised device is hard when many endpoints share a key. | |
| Recommendation — Replace enduring shared keys with short-lived, rotatable credentials. Reduce the privileges attached to each device credential. Design device offboarding so one compromised endpoint can be disabled cleanly. | ||
| NIST SP 800-63 | AAL2 — Authentication Assurance Level 2 | Strong device authentication should exceed weak shared-secret patterns. |
| Recommendation — Adopt stronger authenticators where device assurance must be raised. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Shared secrets undermine access scoping and revocation for device fleets. |
| Recommendation — Centralise access control and remove credentials that cannot be individually revoked. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | Each device needs a governable identity instead of a fleet-wide shared secret. |
| A.8.5 — Secure authentication | Operational security depends on authenticators that can be managed safely over time. | |
| Recommendation — Assign and govern unique identities for devices that access operational systems. Use authenticators that support secure issuance, renewal, and revocation. | ||
Practitioner Guidance
What to prioritise: Inventory every device class that still depends on a shared key, then rank them by blast radius and replacement difficulty. The highest-risk cases are the ones where a compromise would affect many endpoints, or where physical access is required to change the secret.
What to verify: Confirm that you can revoke one device without revoking the entire fleet. If the answer is no, the key is functioning as a shared infrastructure dependency, not as a device identity control.
Common mistake: Treating “encrypted traffic” as proof of operational security. Encryption can protect data in transit while still leaving you with poor revocation, weak attribution, and an impossible recovery path after secret leakage.
Practitioner takeaway: For low-power devices, the question is not whether a pre-shared key can authenticate, but whether you can safely rotate, isolate, and revoke it at device granularity when something goes wrong.
Related resources from NHI Mgmt Group
- What breaks when developer mode on shared devices is treated as a low-risk convenience setting?
- Why do shared provider keys create operational and security risk in AI application environments?
- What breaks when hardware security keys are managed as standalone devices instead of as part of a lifecycle process?
- Why do shared physical keys and reusable MFA methods create security and operational risk in multi-user facilities?