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). Key pairs can be generated by OTA-Pulse — the private key is returned to you exactly once and is never stored server-side. Keep it in your own HSM or secrets vault; we recommend offline signing for production. If you'd rather not have the private key touch our servers at all, generate it yourself and import only the public key. Either way, the private key never touches the device. The device verifies the signature before installation; any tampered artifact is rejected, deleted, and reported back to the server.
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 binaryblack21@gmail.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 binaryblack21@gmail.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