Every identity and access change is written to a hash-chained, immutable audit trail.
Identity and access management
Internal IAM covers root users, organization admins, operators, approvers, and support roles, each acting through explicitly scoped permissions rather than broad standing access.
PBAC and scoped permissions
Permission-based access control (PBAC) binds specific capabilities to specific roles, so a user’s access maps to exactly what their role requires — not a flat admin/non-admin split.
Multi-factor authentication
MFA applies to accounts with access to fleet operations, reducing the blast radius of a single compromised credential.
Approval workflows for sensitive actions
High-risk operations — wipes, policy exceptions, and other restricted state changes — route through an approval workflow before they execute, so no single operator can take an irreversible action alone.
Audit logging and audit integrity
Identity, access, and permission changes are written to a hash-chained, immutable audit trail designed to be reviewable by an internal compliance or audit function, not reconstructed after the fact from scattered application logs.
Organization data isolation
Every data path is scoped to its owning organization. Cross-organization reads, writes, exports, and access are structurally prevented rather than relied upon as a convention.
Encryption and secrets handling
Secrets, credentials, and signed URL material are kept out of persisted application state, logs, and audit metadata, and are never exposed in API responses or UI messages.
Deployment security
The same identity, approval, and audit model applies across every deployment path — SaaS, self-hosted, hybrid, and air-gapped — so your security posture doesn’t change based on where the control plane runs.
Backup and disaster recovery
Deployment operations planning includes backup and recovery behavior for high-risk changes, so operators have a defined rollback and recovery path rather than an ad hoc one.
Secure development practices
Engineering follows ISO/IEC 27001:2022-aligned secure development practices — least privilege, validated boundaries, safe error handling, and audit-backed writes — as a standing engineering discipline, not a pre-release checklist.
Compliance mapping and evidence
RubusNode’s security program is built around SOC 2 Type II practices and maps to ISO 27001 controls, with compliance evidence organized for buyer review. We describe this precisely as readiness and control alignment, and we distinguish that clearly from a completed third-party certification or attestation.
Common questions
Is RubusNode SOC 2 or ISO 27001 certified?
RubusNode’s security program is built around SOC 2 Type II practices and ISO 27001-aligned control mapping. We describe this as readiness and alignment, and we’re precise about the distinction between that and a completed third-party certification — ask our team for current status and evidence.
How is one organization’s data kept separate from another’s?
Every data path is scoped to its owning organization at the data-access layer, so cross-organization reads, writes, and exports are structurally prevented rather than relied on as an application convention.
What stops a single compromised or malicious operator from taking a destructive action?
Restricted state changes such as wipes and policy exceptions are configured as approval-gated operations, so a single operator cannot execute them unilaterally — a second, scoped approver must review and approve first.
See how RubusNode fits your endpoint fleet.
Book a walkthrough for this capability and the rest of the platform.