CrashPlan administrators can see endpoint and archive context, alter backup behavior, manage identities, and restore user files. Those capabilities solve real recovery problems, but placing them in one standing super-user account creates an unnecessary path from a compromised credential to policy change, privacy exposure, or archive deletion.
The product’s security controls span several planes. Organization roles define what a person can do, local authentication and SSO decide where login controls live, API clients and tokens govern automation, push and lock behavior determine whether endpoint settings actually change, and restore roles decide who can browse or deliver another user’s data.
This playbook separates those planes and connects them to offboarding. It also highlights plan boundaries, because cold storage, API access, directory features, restore methods, and administrative options can differ between CrashPlan for Enterprise, MSP configurations, and CrashPlan for Small Business.
Key decisions at a glance
- Build CrashPlan roles from actual duties and organization scope, Customer Cloud Admin is a super-user role, while restore, audit, identity, MFA, help-desk, user, and device work can be separated.
- CrashPlan console 2FA applies to locally authenticated users, while MFA for SSO users belongs in the identity provider, local authentication exceptions inside an SSO organization still follow CrashPlan’s local 2FA controls.
- Migrate automation from deprecated basic authentication to short-lived token or API-client authentication before enforcing 2FA, and verify that the current product plan includes the required API access.
- Treat backup selections, exclusions, retention, visibility, web restore, and encryption-key settings as governed production changes, saving, pushing, locking, and inheriting are not equivalent states.
- Offboarding must distinguish block, device deauthorization, and destructive deactivation, including Enterprise cold-storage windows, Small Business deletion behavior, legal hold, licenses, and restore ownership.
Map Roles, Organization Scope, and Restore Authority to Real Work
Begin with a restricted access register containing the administrator’s individual identity, business owner, employment or provider relationship, authentication source, organization scope, assigned CrashPlan roles, restore capability, API access, emergency purpose, approval, last use, last review, and planned removal. Do not publish usernames, email addresses, customer names, organization IDs, device names, archive details, identity-provider groups, role exports, or screenshots of the console tree. Translate work into the narrowest documented role combination. Customer Cloud Admin is a super-user role with all possible permissions and should be limited to people who genuinely need complete control. An Audit Log Viewer can review events but does not gain general administration. Org Help Desk and Cross Org Help Desk variants differ by scope and restore behavior, while no-restore variants help separate support visibility from access to user content. Admin Restore and Admin Restore Limited supply restore permissions but do not alone provide console or app access, so pair them only with an appropriate access role. Org Computer Modify and Cross Org Computer Modify address device-setting work without automatically granting every user or organization operation. Identity Management Administrator is powerful because its elevated role-management permission can assign roles, isolate that function from routine help-desk work. Multi-Factor Auth Admin manages local-user 2FA within its organization hierarchy but requires another role for user and organization access. Define restore authority as a data-access control, not a technical checkbox. Separate personal restore, limited web restore, full web restore, and push restore. Decide who may browse another user’s file tree, select a source archive, choose a target device, overwrite existing files, preserve original permissions, or deliver data to a controlled investigation location. CrashPlan roles can expose permissions such as restore, pushrestore, and select with personal, limited, or all scope. Pair sensitive restores with a ticket, requester identity, data owner, purpose, legal basis, source device, target, options, approval, evidence location, and deletion date. Test denied actions as well as allowed work. A help-desk role that can unexpectedly restore executive data is not least privilege merely because its name sounds limited. Use non-production users, devices, and files to prove organization boundaries and restore separation after every role-model change.
- Register every administrator’s identity source, organization scope, role combination, restore capability, API access, owner, approval, and removal date.
- Reserve Customer Cloud Admin for bounded super-user work and use audit, identity, MFA, help-desk, device, user, and restore roles separately.
- Treat browse, web restore, push restore, target selection, overwrite, and permission choices as distinct data-access powers.
- Require a ticket, owner, purpose, approval, source, target, restore options, restricted evidence, and cleanup date for administrative restores.
- Prove both allowed and denied actions with synthetic users and archives whenever roles or organization boundaries change.
Align Local 2FA, SSO MFA, Recovery, and API Tokens
Document the authentication source for every privileged account. CrashPlan’s console two-factor settings apply to locally authenticated users. For an organization using SSO, the identity provider controls MFA, conditional access, device requirements, sign-in risk, session lifetime, and authentication recovery. A user configured as a local authentication exception in an SSO organization returns to CrashPlan’s local 2FA requirements, so emergency and service accounts cannot be omitted from the local review simply because the parent organization uses SSO. Prefer supported authenticator-app TOTP for local privileged users where practical, protect enrollment and reset, and restrict email-code reliance according to the organization’s risk model. Never share administrator identities. Build a monitored emergency-access path that is independent of the ordinary SSO failure domain, narrowly scoped, physically and logically protected, and tested on a schedule. Record who may reset local 2FA, who can restore IdP access, how suspicious unfamiliar-device or reset events are investigated, and how administrators reach support without publishing customer or console details. Test recovery without copying seed secrets, TOTP values, backup codes, passwords, API secrets, tokens, or console URLs into tickets. Inventory every script, report, integration, CLI profile, and automation account that reaches the CrashPlan API. CrashPlan states that basic authentication is deprecated, that console 2FA can break basic-auth automation, and that integrations should move to token authentication. Prefer an API client and short-lived bearer token when the current product plan supports that method. A user-password token flow still depends on a local account and may require a TOTP header, SSO credentials do not substitute for the documented local API requirement. Apply the least role needed for each resource, isolate client IDs and secrets in an approved vault, rotate them, restrict execution hosts, avoid shell-history exposure, validate TLS, and log use without logging token bodies. Before migrating, map every endpoint, method, version, pagination rule, output field, and failure path. Run old and new read-only reports in parallel with sanitized comparison, then disable stored passwords and revoke obsolete secrets. Confirm product entitlement because CrashPlan documents API access as plan-dependent. If an automation is not permitted by the plan, use supported console exports and a controlled manual process instead of bypassing access controls.
- Identify whether each privileged account is local, SSO, or a local exception, and place MFA and recovery control in the correct system.
- Protect a narrow monitored emergency account, test recovery, and keep passwords, TOTP material, recovery secrets, console addresses, and identity exports out of tickets.
- Inventory every API script and migrate deprecated basic authentication to supported token or API-client authentication before enforcing local 2FA.
- Store API client secrets in a vault, use short-lived bearer tokens, limit roles and hosts, rotate credentials, and redact request and response evidence.
- Verify API entitlement and local-authentication prerequisites for the current CrashPlan plan instead of assuming SSO or a marketing feature list grants access.
Govern Inherited, Pushed, Locked, and Encryption Settings
Create a backup-policy register for every CrashPlan organization. Record the parent, inheritance state, user populations, device count, data-selection intent, global and cloud exclusions, filename exclusions, backup schedule, frequency, version retention, deleted-file behavior, CPU and battery settings, bandwidth, proxy, excluded interfaces, alert thresholds, client visibility, web-restore policy, encryption-key policy, owner, approver, pilot, rollback, and review date. The organization’s saved defaults, an inherited value, a pushed value on an existing endpoint, and a locked value are different states. Saving a setting establishes it for future devices, pushing sends it to current devices while leaving user choice, locking pushes the setting and prevents user changes. A device-level edit is pushed automatically. When an organization inherits device defaults, disable inheritance only when a documented exception justifies divergence. Model blast radius before pushing or locking across parent and child organizations, and use the console’s affected-device summary as one input rather than the only evidence. Verify representative endpoints after the queue completes. Control file selections and exclusions as data-deletion decisions. Lock high-value inclusions where business policy requires them, but test platform paths and user-home substitutions. Global exclusions remove matching data from all archives and can affect preservation policies, cloud exclusions remove matching files from cloud archives while local destinations may behave differently. An API exclusion update is Enterprise or MSP specific and can overwrite existing exclusions, so read and preserve the current set first. Require application owner evidence, a sample match and nonmatch set, approval, a restore test, and a removal date for every non-default exclusion. Treat encryption choices as recovery architecture. CrashPlan’s Standard archive-key setting supports ordinary authorized restore workflows and is recommended in its console guidance, locking it prevents users from choosing a configuration that can block administrator restores. Custom key security shifts responsibility to the customer, and CrashPlan states that support cannot recover a lost custom key. A stronger or elevated key policy can be irreversible in some upgraded environments. Before any change, document who can restore, where key material is protected, how succession works, what emergency access means, which restore methods remain available, and how the organization will test without exposing the key. Web restore can be disabled and locked where the risk of server-side administrative decryption outweighs its operational benefit. Do not make that choice during an incident, approve it with the recovery design and test the remaining restore path.
- Register inheritance, selection, exclusions, frequency, retention, performance, network, alerts, visibility, web restore, encryption, owner, pilot, rollback, and review for every organization.
- Distinguish saved defaults, inherited values, pushed changes, locked controls, and actual endpoint state before claiming a policy is enforced.
- Treat global, cloud, filename, and API-managed exclusions as archive-impacting changes with tests, approval, backup of the prior configuration, and removal criteria.
- Lock Standard archive-key policy when administrator recovery is required, and never enable a custom key without protected custody, succession, and a tested restore design.
- Pilot every broad push or lock, verify representative endpoints after the update queue clears, and preserve only sanitized evidence outside restricted administration records.
Offboard Without Confusing Access Revocation and Archive Deletion
Build separate runbooks for user departure, administrator departure, lost device, stolen device, device replacement, contractor end, provider transition, legal hold, and license cleanup. Revoke identity-provider sessions and groups, rotate shared or API credentials, remove CrashPlan roles, transfer organization and policy ownership, preserve audit evidence, and confirm emergency administration before disabling the departing operator. For endpoint users and devices, select the CrashPlan action based on the required outcome. Blocking revokes access while existing data remains and background backups can continue, the user or device still consumes a license. Device deauthorization signs the user out and stops activity until authentication resumes, without deleting the archive. Deactivation is destructive: it stops backup, revokes access, and moves associated archives toward deletion. These are not interchangeable substitutes for offboarding. Verify the current product behavior before deactivation. CrashPlan for Enterprise environments commonly use cold storage, where deactivated archives remain recoverable for the configured window and still consume a license until purged. CrashPlan’s current guidance notes a 14-day default but organizations may configure retention. CrashPlan for Small Business does not provide the same cold-storage safety net, deactivated device archives are marked for deletion and reactivation will not recover them. Users on legal hold cannot be deactivated, though blocking may still be appropriate. A customized app that auto-registers users can also reactivate a device unless it is blocked before deactivation. Place destructive actions behind a second-person check that confirms user, organization, device, archive, legal hold, retention, replacement status, data owner, last successful backup, restore need, and current cold-storage policy. Change a departing user’s email only when needed for the documented account-move process, and avoid identity reuse that attaches a new employee to an old archive. If a new device will inherit an archive, follow the replacement workflow instead of deactivating the source prematurely. After each offboarding event, verify roles, local and SSO access, tokens, devices, archive state, license state, alert recipients, policy ownership, and restore authority. Preserve a restricted technical record and a sanitized completion note. Schedule periodic access reviews that find inactive accounts, dormant API clients, local exceptions, standing super-users, unowned policies, excessive restore rights, and archives approaching permanent purge. Security is complete only when the organization can prove both that unauthorized access is closed and that required recovery remains possible.
- Use separate workflows for departure, lost device, replacement, provider transition, legal hold, administrator removal, and license cleanup.
- Choose block for access revocation with continued backup, deauthorize for device sign-out and paused activity, and deactivate only for an approved destructive archive lifecycle.
- Confirm Enterprise cold-storage retention, Small Business immediate-deletion behavior, legal hold, auto-registration, archive ownership, and restore need before deactivation.
- Remove roles, IdP groups, local exceptions, sessions, API clients, secrets, alert recipients, and policy ownership with a second-person check.
- Review inactive identities, standing super-users, restore powers, local MFA exceptions, dormant tokens, orphaned settings, and archives nearing purge on a fixed schedule.
Vendor documentation and ALLMSP resources
- CrashPlan: User Roles reference
- CrashPlan: Understanding two-factor authentication
- CrashPlan: API authentication methods
- CrashPlan: API syntax and usage
- CrashPlan: CrashPlan console settings
- CrashPlan: Configure device backup settings
- CrashPlan: How CrashPlan handles encryption keys
- CrashPlan: Enabling custom key security
- CrashPlan: Understanding block, deauthorize, and deactivate
- CrashPlan: Deactivate and reactivate users and devices
- CrashPlan: Organizations reference
- CrashPlan: Include and exclude files for backup
- ALLMSP Crashplan Software Support
- ALLMSP Crashplan Support, Setup and Optimization
- ALLMSP Data Backup and Recovery
- ALLMSP Business Software Support
- ALLMSP Managed IT Services
- Contact ALLMSP
Frequently Asked Questions
Should every CrashPlan administrator have Customer Cloud Admin?
No. Customer Cloud Admin is a super-user role with complete environment control. Assign it only for duties that require that reach. Routine audit, help-desk, device, identity, MFA, user, and restore work can be separated with narrower roles and organization scope, then tested for both allowed and denied actions.
Does CrashPlan console 2FA protect users who sign in with SSO?
CrashPlan’s local two-factor settings apply to locally authenticated users. SSO users receive MFA and conditional-access controls from the identity provider. A local authentication exception inside an SSO organization follows CrashPlan’s local 2FA rules, so emergency and exception accounts need a separate documented review.
Why can enabling CrashPlan 2FA break API automation?
A script using standard basic authentication cannot complete the additional local verification flow and may fail when 2FA is enabled. Inventory integrations first, migrate them to supported token or API-client authentication, verify plan entitlement and role scope, and revoke saved passwords after validated parallel testing.
Is CrashPlan basic API authentication still recommended?
No. CrashPlan labels basic authentication deprecated. Prefer a supported API client that obtains a short-lived bearer token when the current plan permits it. Protect client secrets in a vault, scope the role, restrict execution hosts, rotate credentials, and never place tokens or full API responses in ordinary tickets.
What is the difference between pushing and locking a CrashPlan setting?
Pushing applies a setting to existing endpoints but still allows a user to change it later. Locking pushes the setting and prevents user changes. Saving an organization default can affect only future devices. Verify the update queue and representative endpoint state instead of inferring enforcement from the saved console value.
Can a CrashPlan exclusion delete data from archives?
Yes. Global and cloud exclusions can remove matching data from existing archives as well as future backup. Some API exclusion operations can overwrite the current list and are plan-specific. Preserve the prior configuration, test matches and nonmatches, approve the change, and perform a restore check before broad use.
Should an organization use a CrashPlan custom archive key?
Only after accepting the recovery consequences. CrashPlan cannot recover a lost custom key. Document protected custody, succession, emergency access, permitted restore methods, and regular restore tests first. If administrator recovery is required, CrashPlan’s Standard key policy and an appropriate lock may better match that operating model.
What is the difference between blocking and deactivating in CrashPlan?
Blocking revokes user access while backups and archives can remain active, and the account still consumes a license. Deactivation stops backup and starts the archive-deletion lifecycle. Confirm legal hold, restore need, replacement plans, cold-storage policy, and product plan before using the destructive action.
Does CrashPlan for Small Business have Enterprise cold storage?
No. CrashPlan’s current deactivation guidance says cold storage is not available in CrashPlan for Small Business, a deactivated device archive is marked for deletion and reactivation will not recover it. Enterprise retention is configurable, so verify the actual organization setting rather than assuming the default window.
What should a CrashPlan access review verify?
Review individual ownership, authentication source, local exceptions, MFA, organization scope, roles, restore authority, API clients, last use, policy ownership, alert recipients, emergency access, and removal dates. Also test denied actions and identify super-users, dormant tokens, orphaned settings, inactive accounts, and archives nearing permanent purge.
