ClientSt0r is designed with practical security controls expected by infrastructure-focused MSPs. Security is treated as an operational requirement, not a marketing checkbox.
Access to ClientSt0r is controlled through layered authentication and a granular permission system. Every user has the minimum access required for their role — no implicit elevation, no shared admin accounts.
Granular per-module access control across all platform functions. Roles are assigned per user per organisation. Least-privilege is the default — access is granted explicitly, not inherited broadly.
Time-based one-time passwords enforced at login. Configurable globally or per user by administrators. Standard authenticator app compatibility — no proprietary MFA vendor required.
Session lifetimes are administrator-configurable. Sensitive operations require re-authentication regardless of active session state. Idle sessions are terminated at the configured threshold.
SAML and OIDC support for enterprise identity provider integration. Users authenticate through your existing Entra ID tenant — ClientSt0r does not store the identity provider credential.
Bind-based LDAP authentication with group synchronisation. User and group mappings configured by the administrator. Supports both on-premises AD and LDAP-compatible directory services.
Full local user account management as an alternative to directory integration. Password policy, forced reset, and account lockout configurable from the admin interface without external dependencies.
The credential vault is designed to hold sensitive client infrastructure passwords and secrets. Encryption is applied at rest with keys stored server-side — no credential data leaves your deployment to a vendor cloud.
ClientSt0r includes several network-layer and application-layer controls to reduce exposure of the admin interface. These work alongside standard server hardening practices — they are not a substitute for them.
Dependency and vulnerability management is part of the development and deployment process. Several tools are used to identify known-vulnerable components before and after deployment.
Automated dependency and CVE scanning integrated into the development pipeline. Python package dependencies are checked against Snyk's vulnerability database. Known-vulnerable packages are flagged and prioritised before release.
Recurring checks against installed OS packages for known-vulnerable components. Unpatched system packages are a common attack vector in self-hosted deployments — this scanning surfaces them before they become an exposure.
Proactive alerting before certificate and domain registrations expire. Expired TLS certificates are a predictable and avoidable failure mode. Configurable alert thresholds — defaults notify well ahead of expiry.
Endpoint availability tracking with configurable alert thresholds. Monitors the platform's own interfaces and optionally external services relevant to your clients. Alerts via configured notification channels.
Internal security intelligence platform used during development for CVE correlation and exposure assessment. ExploitHound is used alongside Snyk and manual review to identify risk before it reaches production deployments. See exploithound.com.
Security-relevant dependency and platform updates are prioritised in the release cycle. High and critical CVEs in direct dependencies are addressed out-of-band where possible rather than waiting for scheduled feature releases.
All sensitive operations generate an immutable audit log entry. Logs are viewable by administrators in-platform, exportable to CSV for compliance review, and charted for trend visibility. Retention is configurable per deployment — there is no forced expiry or cloud sync.
| Event Category | What Is Logged | Fields Captured |
|---|---|---|
| Authentication | Login success and failure, logout, session expiry, 2FA events, SSO assertions | Timestamp, username, IP address, user agent, outcome |
| Vault Access | Credential read, copy, edit, delete, field-level reveals | Timestamp, user, credential ID, organisation, action type, IP |
| Permission Changes | Role assignment and removal, permission grant and revoke, admin elevation | Timestamp, acting user, target user, permission changed, before/after state |
| Admin Operations | User creation and deactivation, integration config changes, system setting changes | Timestamp, admin user, action, target object, changed values |
| Organisation Changes | Org creation, modification, merge, deactivation | Timestamp, user, org ID, action, changed fields |
| API Access | API key usage, scope violations, high-volume requests, key creation and revocation | Timestamp, key ID, endpoint, IP address, response code |
| Security Events | GeoIP blocks, Fail2ban triggers, rate limit hits, lockout events | Timestamp, IP address, country (where available), event type, action taken |
Secure deployment practices are documented and followed in the default install. The goal is that a standard installation is reasonably hardened without requiring the operator to know every configuration detail in advance.
Self-hosted software shifts security responsibility toward the operator. That is the tradeoff that comes with the control and ownership. The following is worth stating clearly.
ClientSt0r does not make unverifiable security claims. It is a self-hosted application — your deployment, your configuration, your responsibility. The security controls described here are included to support good operational practice. They do not substitute for: