1. Encryption in three layers
IoT data needs protection in transit, at rest, and in use. TLS and mTLS cover the control plane and the data plane. Volumes, object storage, and backups use AES-256, or an SM algorithm of the same strength. A field that is especially sensitive — a digest of biometric data, or a payment token — can take envelope encryption in the application, so a database administrator still cannot read the plaintext. The SimtoLink Device Management Platform connects to the customer's cloud KMS, an HSM they run, or a hybrid hold-your-own-key (HYOK) setup. In a compliant deployment the key material does not leave the customer's control.
Three layers
TLS and mTLS in transit, AES-256 or SM at rest, and envelope encryption in the application. Each state of the data has its own layer.
BYOK and HYOK
The customer holds the key, or holds it in a hybrid arrangement. The key material stays inside their control, which is what data sovereignty asks for.
Rotation and a grace window
Rotate the CMK and the DEK on the policy schedule. Both keys decrypt during a grace window, and the calendar lines up with credential expiry.
How a key is governed
| Capability | What it does |
|---|---|
| In transit | TLS 1.2+ and mTLS protect the control plane and the data plane |
| At rest | AES-256 or SM on database volumes, object storage, and backups |
| Envelope encryption | A second layer in the application on sensitive fields, so a DBA cannot read the plaintext |
| BYOK / HYOK | Connect the customer's cloud KMS or their own HSM. Key material stays in their control |
| Rotation and audit | Rotate the CMK and the DEK on a schedule. Every action is audited, and the roles are split |
2. Split duties and approval
The KMS administrator, application operations, and the security auditor are different roles. The same person does not both hold the keys and review the logs. A high-risk action requires MFA and a second reviewer, and it is written to the audit trail.
3. Rotating the CMK and the DEK
The customer master key (CMK) and the data encryption key (DEK) rotate on the policy schedule, with a grace window in which both keys can decrypt. Line that calendar up with credential rotation and certificate expiry, so the changes do not all land at once.
4. Keys on the device
A device private key should be generated on a secure line, or inside a secure element, and it should not be exportable. A session key is short-lived and supports forward secrecy. The cloud stores only the wrapped key blob and the metadata.
5. Compliance evidence
The encryption policy, the algorithm list, the key classification, and the rotation record go into regulatory mapping. That is what China's classified cybersecurity protection (MLPS) and industry rules ask for on the confidentiality of important data.
6. Drills, without taking the service down
On a schedule, simulate a KMS region that is unreachable, a quota that is used up, and a permission that was set wrong. Confirm the service can fall back to read-only or to a read cache, so confidentiality does not mean a full outage. File the drill report.
7. Borders and residency
The region that holds the key and the ciphertext has to follow the data residency policy. Copying ciphertext across a border needs a check against the rules for cross-border transfer.
8. Summary
Key governance is the algorithm, the life of the key, and the way the organization works, together. The SimtoLink Device Management Platform provides a pluggable KMS, rotation scheduling, a closed audit loop, and drill tools. Further reading: mutual TLS and the device trust root. For a review of your key architecture, contact the SimtoLink security team.
Appendix. Keeping keys operable after go-live
A key design that works in a proof of concept still needs three habits before it carries production data. On a pre-release batch built like production, rehearse a connection storm, a disk that fills, certificate rotation, and a failure across regions, and keep the result as an acceptance checklist. Write KMS error rates, alert thresholds, the on-call path, and how long audit records are kept into change management, so a rotation can be traced and undone without relying on one administrator. Once a quarter, engineering, operations, security, and data should check whether those signals still explain the risk, and tie the actions to tickets and the release cadence. The console, open API, and export on the SimtoLink Device Management Platform stay in service: observable, orchestrable, and auditable. If the KMS has to meet your ITSM, IAM, data lake, or edge cluster, the SimtoLink solutions team can review the architecture with you and return an implementation note and a risk list.