We hold a key that can vouch for your devices.

Tenant isolation

Every organization gets its own root and its own intermediate, generated for it alone. There is no shared root above you, so no other customer's CA — and no certificate issued to them, by mistake or otherwise — chains to anything your network trusts. That separation is structural. It does not depend on us applying a policy correctly on every issuance.

Each tenant's CA also runs as its own process with an environment of its own, so the component that parses enrollment requests off the internet holds that tenant's material and nothing else.

Where you give us the domains you issue into, we apply X.509 name constraints to your intermediate and then verify that the certificate we built actually carries them, rather than reporting the intention. A constrained intermediate cannot issue outside your namespace even if the machinery above it is asked to.

Keys and who holds them

Device private keys never reach us. Under SCEP, the device generates its own key locally and sends only a signing request. There is no step in the protocol where a key travels, and nothing in our design would have somewhere to put one.

Your CA private keys are encrypted at rest with AES-256-GCM. The key that decrypts them is not in the database it protects and not in the application's configuration file: it is held in the operating system's credential store and released to the service only as it starts. A database dump, a stray backup or a copy of the application directory yields ciphertext and nothing that opens it.

Everything this service writes to disk is private to its own account. SCEP challenge passwords and two-factor secrets are encrypted with the same key as the CA material.

Backups are encrypted with a key the server does not hold, so taking the server does not hand over its history.

If you would rather we did not hold your trust anchor at all, you do not have to let us: sign our intermediate with your own offline root. We issue beneath it, your root key never leaves your infrastructure, and the worst case on our side shrinks to a constrained intermediate you can revoke yourself.

What gets a certificate

A SCEP enrollment is authorized by a challenge password, and it is worth being blunt about what that means: anything holding a valid challenge can obtain a certificate from your CA. That is how SCEP works everywhere, not a shortcut here.

So the challenge is treated as a credential. It is stored encrypted, shown only to members of your account who are allowed to see it, rotatable in one action from the dashboard, and every disclosure of it — including generating an MDM profile that embeds it — is recorded in your audit log.

For the cases where a fleet-wide secret is too blunt, enrollment can instead run against a token that expires, has a limited number of uses, and can be revoked, so a profile handed to one device does not stay valid forever.

The enrollment relay itself is rate limited per tenant, so one noisy fleet cannot exhaust anybody else's budget, and the request body is capped well below anything a genuine enrollment needs.

Portal access

Passwords are hashed with bcrypt at 12 rounds and are never recoverable — we can reset one to an address you control, and that is all. A minimum length is enforced, an account locks for 15 minutes after 10 failed attempts, and a login for an address that does not exist costs the same time as one that does, so the form cannot be used to enumerate accounts.

Two-factor authentication is TOTP, and each code is single-use: a code captured in flight cannot be replayed even inside its own 30-second window. Anything that changes what your devices trust requires that second factor — migrating your trust anchor is the clearest example.

Sessions are a signed cookie that is HTTP-only, restricted to this site, marked SameSite, and expires after two hours. Team access is by invitation with roles, and every invitation, role change and removal is in the log.

The audit log

Every sign-in, failed sign-in, password change, certificate issuance, revocation, challenge rotation, membership change and administrative action is recorded with the time, the account, the IP address and the user agent. The log is append-only and hash-chained: each entry commits to a digest of its own contents and of the entry before it.

What that buys you, precisely:

• An edited entry is detectable from the entry itself. Your audit page re-checks every row it renders and flags one that does not match.
• A deleted entry is detectable only across the whole chain, which interleaves every account on the platform. We verify it end to end on a schedule; your own slice cannot prove that on its own, and the page says so rather than implying otherwise.
• The log lives on the machine it audits. Somebody with that host can rewrite it. A hash chain does not prevent that — it makes it visible instead of silent, which is a smaller claim and the true one.

You can export your own log at any time, and the export is itself recorded in the log it exports, so the next one shows who took the last. We cannot delete entries on request; they age out on the retention schedule in the privacy policy.

The platform

The portal serves a strict content security policy: scripts load only from this origin, with no inline execution, no eval, and no third-party script host beyond the anti-automation check on the registration form. Framing is refused outright, referrers are not sent, and every response is served over HTTPS.

Authentication endpoints are rate limited by IP as well as per account, and the machine-facing paths carry their own ceilings.

There is no analytics, no advertising and no tracking on any page. The only cookie we set is your session; the registration page additionally carries an anti-automation check, which sets one of its own.

The platform has been through a full security review of the certificate machinery and the host around it, including active testing — a rogue CA built to probe the OCSP responder, name constraints checked by having a validator reject an out-of-namespace certificate, and header spoofing attempted against the live rate limiter. Findings were fixed, and the review is repeated as the system changes.

Your data

We hold your email address, your organization name, the subject names of the certificates you issue, your security records, and what you paid. We never see card details — those go to the payment processor directly.

We do not sell personal information and we do not share it for anyone's marketing. The operators who process data on our behalf, the retention period for each kind of record, the legal basis for processing it, and your rights under POPIA are all set out in the privacy policy.

Revocation and outages

Certificates already on your devices do not depend on us being reachable. They keep authenticating for as long as they are valid. What needs the service is enrolling a new device, re-enrolling an existing one, and fetching a fresh revocation list.

Your CRL is published at a fixed address and regenerated the moment you revoke. It is also refreshed well before it can expire, because a validator handed a CRL whose nextUpdate has passed does not fall back to trusting everything — it fails the authentication. An OCSP responder answers for the same certificates.

If you are deploying this on a network you cannot afford to lose, mirror the CRL to an address you control. This is our recommendation for any production deployment, not an advanced extra. The reasoning is short: an expired CRL is a hard authentication failure, and while an issued certificate does not need us, a fresh revocation list does. Mirroring moves that last dependency onto infrastructure you run. Certificates can be stamped with your mirror's address instead of ours, so the devices never look our way at all. The setup guide has the cron job; it is about four lines.

The trade is worth stating plainly: once you mirror, keeping the mirror fresh is yours. A mirror that silently stops updating fails authentication exactly as an expired CRL from us would. Monitor it.

Reporting a vulnerability

If you have found a vulnerability, tell us and we will work it rather than argue about it. Write to us with enough detail to reproduce it. This page is the disclosure policy referenced by our security.txt.

What we commit to

• We acknowledge a report within 3 working days.
• We give you an assessment and a fix timeline within 10 working days.
• We keep you updated while it is being fixed, and we tell you when it ships.
• We credit you by name or handle if you want the credit, and stay quiet if you do not.
• We will not pursue or threaten anyone who reports in good faith under this policy.

What we ask

• Give us a reasonable window to fix it before publishing — 90 days is our default, and we would rather agree a shorter one with you than have you wait on a fix that is already out.
• Test against your own tenant. Do not touch another customer's CA, certificates or account data, and stop at the point where you have proved the finding.
• No denial-of-service testing and no automated scanning against the SCEP or OCSP endpoints. Live network authentication depends on those, and a device that cannot reach them cannot get onto the network.
• If you do reach customer data by accident, stop, tell us, and delete it.

We do not run a paid bug bounty. This is a small operation and we would rather promise a real response than a reward we cannot fund.

If a breach affects your personal information, we notify you and the Information Regulator as POPIA requires.