> ## Documentation Index
> Fetch the complete documentation index at: https://altostrat.io/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Control Plane Policies

> Use control plane policies to define which router management services are enabled and which source networks can reach them.

Control plane policies define the management services SDX should allow on your MikroTik routers. They centralize settings for WinBox, SSH, HTTP, HTTPS, Telnet, FTP, API, and API-SSL access, including service ports and trusted networks.

## Prerequisites

Before you change a policy, make sure you have:

* Permission to create or update control plane policies.
* A trusted-network list in CIDR format.
* A recent configuration backup for any production site you will affect.
* A maintenance window for broad rollout.

## How Policies Work

When you save a control plane policy and attach it to sites, SDX records the policy and updates the affected site assignments. Device-side enforcement is delivered through the platform's management and job model, so a site must be reachable before the router can receive and apply the change.

The policy model validates that:

* Each management service has an enabled or disabled state.
* Each service uses a valid TCP port.
* Service ports do not conflict with each other.
* Trusted networks and per-service networks use valid CIDR notation.

<Note>
  If your account has no policy yet, SDX creates a default policy for the customer. The default policy is protected from deletion and is used as the fallback when a custom policy is removed.
</Note>

## Create a Policy

<Steps>
  <Step title="Open Control Plane policies">
    Go to **Policies > Control Plane**.
  </Step>

  <Step title="Create the policy">
    Select **Add**, enter a clear policy name, and choose whether you need custom input rules.
  </Step>

  <Step title="Set trusted networks">
    Add the CIDR ranges that should be allowed to reach management services.
  </Step>

  <Step title="Configure services">
    Enable only the services you need. Confirm ports are unique across services.
  </Step>

  <Step title="Attach sites">
    Select the sites that should use the policy, then save.
  </Step>
</Steps>

## Roll Out Safely

For production changes:

1. Apply the policy to a low-risk test site.
2. Confirm WinBox or SSH access behaves as expected.
3. Review the site orchestration or job history for failures.
4. Apply the policy to a small batch.
5. Expand to the remaining sites after validation.

<Warning>
  Control plane mistakes can lock your team out of management services. Keep at least one known-good access path and a recent backup before changing production management policy.
</Warning>

## Common Policy Decisions

<CardGroup cols={2}>
  <Card title="Disable Unused Services" icon="power">
    If your team does not use Telnet, FTP, HTTP, or non-SSL API access, disable them in the policy.
  </Card>

  <Card title="Restrict Source Networks" icon="network">
    Prefer narrow CIDR ranges for operations networks, bastion hosts, or trusted office networks.
  </Card>

  <Card title="Keep Ports Predictable" icon="route">
    Use a documented port standard so support staff know what to expect during incidents.
  </Card>

  <Card title="Stage Changes" icon="list-checks">
    Attach the policy to a small number of sites before applying it fleet-wide.
  </Card>
</CardGroup>

## Troubleshooting

If a policy does not appear to apply:

* Confirm the site is online.
* Confirm the site is attached to the intended policy.
* Check whether the router has picked up the queued work.
* Review the orchestration or job history for the site.
* Verify the source IP you are connecting from is inside an allowed CIDR.

<Card title="Troubleshooting" icon="life-buoy" href="../resources/troubleshooting" arrow="true">
  Use the fleet troubleshooting checklist for policy and job-delivery issues.
</Card>