Security
OTA-Pulse is built security-first — signed firmware, strict access control, encrypted transport, and a full audit trail from build to device installation.
Artifact signing
Every firmware artifact is cryptographically signed before deployment.
OTA-Pulse supports RSA-4096 with PSS padding and SHA-256
and ECDSA-P384 with SHA-384 — both verified by the
open-source cryptography library.
Public keys are embedded into device images at build time (read-only filesystem). Private keys are generated on the server and stored in your HSM or vault — they never touch the device. The device verifies the signature before installation; any tampered artifact is rejected, deleted, and reported back to the server.
This section describes the embedded Linux agent. MCU firmware uses a different chain: images are signed as MCUboot payloads with Ed25519 or RSA-2048, and MCUboot itself is the authoritative verifier on the device at boot. The server verifies that signature on upload for unencrypted images; an encrypted image stays sealed to the server, which checks only that a signature is present. MCU images can additionally be encrypted per device, and the SDK refuses to install a firmware version older than the one already running unless you explicitly allow downgrades. See OTA-Pulse for MCU.
Artifact signing deep-dive →Access control
Organizations are the primary tenancy boundary — all resources (devices, deployments, signing keys) are scoped to an org. Within each org, four roles enforce least-privilege access: Owner, Admin, Member, and Viewer.
API keys can be issued with narrowed scopes for CI pipelines and automation. Public self-registration is disabled by default; admins invite users through the console or admin API.
RBAC reference →Transport security
All production traffic uses HTTPS-only endpoints. Devices communicate with the server over TLS; plain-HTTP connections are not accepted in production deployments.
CORS origins are configured per deployment — only the listed dashboard origins are accepted by the API server. Cross-origin requests from unlisted origins are rejected at the framework layer before reaching any handler.
Audit logging
Every significant action — deployment created, device decommissioned, signing key revoked, role changed, signature verification attempt — is recorded in an append-only audit log with actor identity and timestamp.
Logs are available via the REST API and the console audit view, and can be exported for SIEM ingestion. Device-side security events (verification failures, lockdowns) are reported back to the server and appear in the same log stream.
Device lifecycle →Compliance
SOC 2 Type II — in progress. We are actively working toward SOC 2 Type II certification; this work is not yet complete.
Other compliance frameworks (HIPAA, ISO 27001) are on the roadmap. Contact us at security@ota-pulse.com for current compliance status and questionnaire support.
Responsible disclosure
Found a vulnerability? We take security reports seriously and respond within 1 business day.
Please email security@ota-pulse.com with a description of the issue and steps to reproduce. We publish credit for confirmed reports and aim to ship a fix or mitigation within 90 days of confirmation. See our security.txt for the machine-readable version of this policy.
Get started in 5 minutes.
Register your first device, push a firmware update, and watch it land — without touching a serial console.
Open source agent · Self-host or cloud · No vendor lock-in