Plan your Premium deployment

Premium is enabled at the organization level. Every Security Engine in an organization shares its plan, entitlements, alert quotas, and retention. Before you upgrade, decide which organization model fits your situation.

---

Choose an organization model

Model A — One Premium organization

All environments (production, staging, development) belong to a single Premium organization.

Best when:

• All environments need the same retention period, for example for compliance or audit reasons
• Your team investigates attacks across staging and production
• You want one set of centralized allowlists and blocklist subscriptions applied everywhere
• Simplicity matters more than cost separation

Model B — Premium production, Community non-production

A dedicated Premium organization holds only production Security Engines. Staging and development remain in your personal account on Community.

Best when:

• Only production requires advanced protection, higher alert quotas, or extended retention
• You want to minimize cost by excluding non-production engines from the Premium plan
• Production and non-production environments do not share decisions or allowlists

Model C — Multiple Premium organizations

Each business unit, customer, or regulated environment has its own organization, each on Premium.

Best when:

• You are an MSP managing multiple clients and need complete data isolation per tenant
• Different environments have different billing owners or compliance scopes
• You need per-organization quotas, API credentials, and team memberships

Plan behavior

Community accounts receive one additional organization beyond the personal account at no cost. MSPs and enterprises can create unlimited organizations on Premium.

---

Decision checklist

Use this checklist to choose your model.

Question	If yes, consider
Do all environments need the same alert retention?	Model A
Do environments share allowlists or block decisions?	Model A
Does compliance require identical policies across all environments?	Model A
Do only production environments need extended quotas or retention?	Model B
Do you want to avoid paying for non-production engines?	Model B
Do you manage multiple clients or isolated tenants?	Model C
Do different environments need separate billing or API credentials?	Model C

---

What moves and what does not

When you transfer a Security Engine from one organization to another, understand exactly what carries over.

Item	Transferred	Notes
Security Engine	Yes	Engine joins the new organization immediately
Active decisions on the engine	Yes	Engine retains its local decision state
Historical alerts	No	Alerts stay in the source organization
Blocklist subscriptions	No	Must be re-subscribed in the new organization
Centralized allowlists	No	Allowlists are per-organization; recreate in destination
Service API credentials	No	Credentials are scoped to an organization
Organization members and roles	No	Membership is per-organization
Remediation Sync configuration	No	Must be re-enabled in the new organization

warning

Historical alerts remain in the source organization. If you transfer a production engine away from an organization where it has been running, that alert history becomes inaccessible from the new organization. Plan accordingly if you have retention or compliance requirements.

---

Example: splitting production from non-production

This is the most common starting point for teams moving to Premium.

TEXT

BEFORE

Personal organization — Community
├── 10 production servers
├── 5 staging servers
└── 3 development machines

AFTER

Personal organization — Community
├── 5 staging servers
└── 3 development machines

Production organization — Premium
└── 10 production servers

This model keeps non-production engines on Community at no cost while giving production engines the full Premium entitlement set.

If you need uniform policy across all environments, keep everything in one Premium organization instead.

---

Move your Security Engines

Option 1: Transfer via Console

Best for moving individual engines or small batches.

1. Go to Security Engines in the Console.
2. Select the engine you want to move.
3. Use the Transfer action and select the destination organization.
4. Confirm the transfer.

Transfer engine documentation →

Option 2: Re-enroll via cscli

Best for bulk moves, automation, or infrastructure-as-code workflows.

SH

# Retrieve the enrollment key from the destination organization
# Console → Organizations → [your org] → Enrollment Keys

cscli console enroll <ENROLLMENT_KEY> --overwrite

The --overwrite flag moves the engine to the new organization even if it is already enrolled elsewhere.

Option 3: Infrastructure-as-code deployment

If you provision Security Engines with Terraform, Ansible, or Kubernetes, update the enrollment key in your configuration to point to the destination organization and redeploy. New engines will enroll directly into the correct organization.

---

Before you upgrade

Complete this checklist before upgrading an organization.

• Identified which Security Engines belong in the Premium organization
• Transferred engines that need to move (or noted that historical alerts will not follow)
• Noted which blocklist subscriptions need to be re-established after upgrading
• Noted which allowlists need to be recreated in the Premium organization
• Confirmed the organization billing contact and payment method
• Confirmed you have the Organization Admin role

When you are ready, continue to Upgrade and configure Premium →