Security
Access control that works across ship and shore
Crew data is personal data, and it moves between vessels, shore offices and auditors. These are the controls that decide who can reach it, and the trail that shows what happened to it.
The constraint
Why shipboard access is a different problem
Most access-control models assume the user is online and the administrator is reachable. Neither holds on a vessel. Work happens where connectivity is intermittent, the person who could reset a permission is in another time zone, and the consequence of blocking someone is that a drill or a handover does not get recorded at all.
So the model has to survive being offline without becoming permissive. Permissions travel with the role rather than being granted ad hoc, which means a shipboard user can keep working through a connectivity gap inside the boundaries their role already allows, and the record of what they did reconciles with shore when the link returns.
Separation between operators works the same way by design. CruiseControl is multi-tenant: each cruise line operates on its own branded subdomain with isolated data over one continuously improving core. That is the mechanism that lets a shared platform serve competing operators, because the improvements are common and the data is not.
Single sign-on
Staff authenticate with the identity provider you already run, so access follows your existing joiner and leaver process.
Two-factor authentication
A second factor on top of OAuth2 authentication for accounts that reach crew and compliance data.
Role-based access control
Permissions follow the role, so a shipboard trainer, a shore HR manager and an auditor each see what their job requires and no more.
SCIM provisioning
Accounts are created and retired from your directory, which closes the gap where a leaver keeps working access.
Per-operator isolation
Multi-tenant by design: each cruise line runs on its own branded subdomain with isolated data over one shared core.
Three layers
Getting in, reaching data, and proving what happened
Access control decides who can act. Audit trails decide whether you can later show what was done, which is the half inspectors care about.
Who can get in
Single sign-on against your own identity provider, with two-factor authentication on top of OAuth2. Provisioning and de-provisioning run from your directory rather than a list someone maintains here.
What they can reach
Role-based access control, so permissions are a property of the job rather than something granted case by case and forgotten.
What was actually done
Traceable operational history across the fleet, alongside certification and expiry tracking, so the record of who was qualified when is not reconstructed after the fact.
Your requirements
Reviewing this against your own policy
Security requirements differ by operator and by flag state, and a marketing page cannot answer a specific questionnaire. If you have one, the practical step is to put it in front of us directly rather than inferring an answer from a feature list.
Security and compliance are hard to separate here, because the same records that satisfy an auditor are the ones the operation runs on day to day. There is more on that in why audit readiness starts long before the audit and across the compliance writing. For how the platform is structured underneath, see the platform overview; for what connects to it, integrations.
Security
Questions about security and access
OAuth2 authentication, two-factor auth, single sign-on, and role-based access control, so the right people reach the right data across ship and shore.