Why the access model for a fleet tool is different
Most SaaS logins protect your data. A 3CX fleet-management platform is different: a single authenticated session can reach into your customers'production phone systems — pushing a standardized parameter across dozens of PBXes, scheduling a firmware update fleet-wide, or kicking off a restore. The blast radius of one compromised Sikurd account isn't a leaked report; it's every customer's dial tone.
That reframes the threat model. The question stops being "is the password strong?" and becomes "who can ever hold a session, how do they prove it's really them, and what's the record if something goes wrong?" Sikurd answers those three questions with four concrete controls: Microsoft Entra ID SSO, mandatory MFA enforced before any session exists, a hard rule that sign-in can never create a new user, and an audit trail that captures the security-relevant moments. The rest of this post walks each one, grounded in how the platform actually behaves.
SSO via Microsoft Entra ID (Azure AD)
Sikurd supports single sign-on through Microsoft Entra ID (Azure AD). To be precise about scope: that is the onlySSO provider — there is no Google sign-in, no Okta, no generic SAML. That's a deliberate fit for the buyer. The overwhelming majority of MSPs and 3CX partners already live in Microsoft 365, so "sign in with Microsoft" means your techs authenticate with the identity they use all day, under the Entra policies you already maintain: Conditional Access, device compliance, sign-in risk, and — critically — joiner/leaver lifecycle. When you offboard a tech in Entra, their path into the tool that controls your customers' phones closes with it.
For teams that don't use Entra, or for break-glass access, an email-and-password credential is also supported — and it carries the same MFA requirement described below. Both routes resolve to one identity and one role; SSO is an authentication convenience layered on top of the access model, not a parallel system with its own rules.
The no-self-provision guarantee
Here is the part worth dwelling on, because it's the difference between "we have SSO" and "our SSO is safe for a fleet tool." A naive OAuth integration will happily create a brand-new account for anyone who can complete a Microsoft sign-in. For a platform with this much reach, that would be a serious hole: every person in your (often large) Microsoft directory would be one click from a session.
Sikurd closes it at the adapter level. The account-creation path used by OAuth is overridden so that it cannot create new users. When a Microsoft Entra ID sign-in arrives, the platform looks up the incoming email against accounts that were already provisioned in your tenant. If a matching, pre-created account exists, the Microsoft identity is linked to it and the user is signed in. If no account exists, sign-in is rejected with a no_account error and no session is issued. In other words: an administrator must provision a person before they can ever log in — being in your Microsoft directory is necessary but never sufficient. Nobody self-registers into your tenant.
Mandatory MFA, enforced before any session is minted
Multi-factor authentication on Sikurd is mandatory for the roles that can do damage — Owner, Admin, and Super Admin. The reasoning is explicit in the policy: those roles can change tenant configuration, billing, instance credentials, and other users' access, so a stolen password alone must not be enough. (General Member accounts may opt in.)
What matters as much as that it's required is when it's checked. The second factor is verified inline, in the same step as the password — not after a partial login. The session token is only ever minted once both factors pass, which means there is no half-authenticated, "pending MFA" session sitting around to be stolen or replayed. Either you presented a valid password and a valid second factor, or you have nothing. The two-step sign-in UI learns from the server that an account needs a code, then re-submits the credentials together with that code; if the code is missing or wrong, no token is issued.
The three second factors
A single code input on the sign-in form accepts any of three factors, so a user never has to declare which method they're using — Sikurd tries each in turn and records which one matched:
- Authenticator app (TOTP). A standard time-based one-time code (RFC 6238) from any authenticator app. The shared secret is generated server-side, encrypted at rest, and verified with a ±30-second drift tolerance to absorb clock skew between the phone and the server.
- Emailed one-time code.A six-digit fallback for when the authenticator isn't reachable. It's short-lived (10-minute expiry), rate-limited (capped at 5 wrong guesses before the code dies, with a resend cooldown), single-use, and stored only as a hash — defenses sized to a low-entropy code so the one-in-a-million space can't be walked.
- Single-use recovery code.A printed backup for when both the app and email are unavailable. Sikurd issues a set of ten, shows them exactly once, and persists only their SHA-256 hashes, so a leaked database snapshot can't replay them. Each code works exactly once.
The audit trail
Strong gates are only half the story; you also need the record. Sikurd writes the security-relevant authentication moments to an append-only, tenant-scoped audit log:
- Every failed second-factor attempt is recorded (
MFA_CHALLENGE_FAILED) against the tenant, with the account it was attempted for — a forensic trail for credential-stuffing or a stolen password meeting a working MFA wall. - Every recovery-code use is recorded (
MFA_RECOVERY_CODE_USED). Recovery codes are scarce and single-use, so a burn is exactly the kind of event you want surfaced — it usually means a tech lost their phone, or that someone is using a backup code they shouldn't have.
These sit alongside the platform's broader audit log, where every operator-initiated change to a customer PBX — a parameter push, a scheduled update, a settings change — is already captured with a before-and-after trail and an attributable actor. So the security story is continuous: who got in, how they proved it, and what they changed once inside.
Suspended tenants are stopped at the door
One more guard worth calling out: a suspended customer is blocked at sign-in. Whether the user arrives by password, by Microsoft Entra ID SSO, or by magic link, authentication is refused while the tenant is suspended — and any session that was already issued is invalidated on its very next request. The same session check also kills a token immediately if the user is deleted, or if their password was reset after the token was minted. Access doesn't linger past the moment it should end.
What this means for an MSP
Put together, the access model is the boring-in-the-best-way kind of secure. Your techs sign in with the Microsoft identity you already govern. The people who can change customer phone systems are requiredto carry a second factor, and that factor is checked before any session can exist. The OAuth path can never invent an account, so your Microsoft directory isn't a side door. And the moments that matter — a failed challenge, a spent recovery code, a blocked suspended tenant — are on the record.
None of it is a paid add-on or an enterprise tier. Like everything else on Sikurd, SSO, MFA, and the audit trail are included for every account; you simply pay per instance beyond your first three free ones. Locking down the tool that controls every customer's phone system shouldn't be the upsell — it should be the default.