Skip to content

Security FAQ

Common questions from security architects and CISOs evaluating BlokSec.

No. With BlokKey (the mobile authenticator), your private key is generated and stored on your own device, secured by the device’s hardware (secure enclave / TPM). It never leaves the device, and BlokSec’s servers hold only the public key used to verify your signatures.

With BlokBadge (QR sign-in), the key material is split across multiple factors — part held by the server, part carried in the QR code, and your PIN/passcode — and no single part is usable on its own. They are brought together only momentarily to produce a signature.

In neither case does BlokSec hold a usable copy of your private key.

Two recovery paths are available:

  1. Backup restore — If the user previously created an encrypted backup (a QR code secured with a passphrase), they can restore their identity on a new device, and all accounts are recovered together.

  2. Admin re-enrollment — The IT administrator unregisters the user’s devices from the admin console, which revokes the old device and generates a new claim QR code. The user scans this QR code on their new device to re-enroll from scratch.

In both cases, the lost device is immediately revoked. Even if someone finds the phone, they would need the user’s biometrics or device PIN to open the app, and the server-side revocation means the device’s credentials are no longer accepted.

Yes. There are two key reasons:

  1. No password to steal — BlokSec doesn’t use passwords. There’s nothing for a phishing page to capture. Users authenticate by approving a request on their own device, not by typing credentials into a web page.

  2. Device-bound approval — Sign-in requests are delivered as push notifications to the user’s registered device. The user sees the application name, location, and IP address on their phone. A phishing site might trigger a BlokSec sign-in, but the user would see the request details on their phone and can deny it if it looks suspicious.

Keys are revoked through the admin console:

  • Remove a device — Sends a revocation push notification to the device and removes it from the user’s registered devices. The app resets on that device.
  • Unregister all devices — Removes all devices and resets the user’s cryptographic identity (DID). Generates a new claim QR for re-enrollment.
  • Suspend a user — Temporarily blocks all authentication without revoking keys. The user’s credentials remain intact and can be reactivated.
  • Terminate a user — Permanently deletes the user’s identity across all organizations.

Revocation is immediate. Once a device is removed, authentication requests from that device are rejected by the server.

What is the blast radius of a compromised tenant?

Section titled “What is the blast radius of a compromised tenant?”

Tenants are fully isolated. Each organization (tenant) has:

  • Its own set of users and accounts
  • Its own applications and federation configurations
  • Its own encryption keys and certificates
  • Its own data stored in separate database documents

A compromise of one tenant’s admin credentials would affect only that tenant’s users and applications. Other tenants are unaffected. There is no shared key material or cross-tenant data access.

BlokSec is inherently multi-factor. Each sign-in requires:

  1. Something you have — your registered mobile device (possession)
  2. Something you are or something you know — biometrics (Face ID, fingerprint) or a device PIN to unlock the authenticator

For BlokBadge (QR sign-in), an additional factor applies:

  1. Something you know — the PIN or passcode required to reassemble the key material

BlokSec satisfies multi-factor authentication requirements without layering separate MFA products. It combines multiple factors into a single user action (approve on your phone), making it both more secure and more convenient than password + OTP.

How is data encrypted at rest and in transit?

Section titled “How is data encrypted at rest and in transit?”

In transit: All communication between clients and the BlokSec API occurs over TLS (HTTPS). Push notifications are delivered through Apple Push Notification Service (APNs) and Firebase Cloud Messaging (FCM), both of which use encrypted transport.

At rest: User data is stored in MongoDB with encryption at rest enabled at the infrastructure level. With BlokKey, private keys are never stored on BlokSec servers — they remain on the user’s device. Where BlokSec holds key material (for BlokBadge), it stores only a split portion that is not usable on its own.

Standard Implementation
OpenID Connect Full OIDC Provider with authorization code flow, PKCE, and refresh tokens
SAML 2.0 SAML Identity Provider with signed assertions and configurable NameID formats
WS-Federation Passive sign-in support for Azure AD and Microsoft 365 integration