Connect Management and verify the policy you intend to manage.

1. Prepare the connection and its administrators

Complete installation and import your license first. Gather the intended Management address, any Multi-Domain Server domain, and a policy package and layer you can use to verify the connection.

• Management API: the server must expose API v2.1. A later Management release must still expose that contract; older API versions are unsupported.
• Network access: the Naradox API service must be able to resolve and reach the Management API address. Have the Check Point administrator confirm that API access is enabled and permits connections from your deployment.
• Vendor credentials: prepare dedicated Check Point API administrator credentials with the permissions needed for reads and, when planned, changes. Match their access to the intended domain and workflows.
• Naradox authority: an Administrator or Platform operator can manage connectors. With custom roles, this requires connectors:manage. Permission to view the connector inventory alone cannot save settings or request a new connection check.

Connector management does not itself grant rule, log, approval, or policy-installation access. Use an account authorized to read the selected rulebase for the later read check, and follow Access and permissions for team delegation.

2. Add the Management target and API credentials

1. Open Platform > Connectors and choose Create instance. The connector is Check Point.
2. Enter a recognizable Name, such as Production Management. It must be unique among your Check Point instances.
3. Set Base URL to the Management API root, for example https://mgmt.example.com/web_api/. Include the port if your Management API uses a different one. Do not append an API version or command, or include credentials, a query, or a fragment.
4. For a Multi-Domain Server, set Domain (optional) to the intended CMA's exact name or UID. Otherwise leave it empty.
5. Under Authentication, select Configure separate view/write API keys. Enter the read credential in View API key and the change credential in Write API key. For an initial read-only setup, leave the write key empty and add it before testing changes.

Reads and the connection check require the view key. Naradox never falls back to the write key when the view key is missing or fails. Use separate least-privilege API administrators where appropriate; multiple keys for the same underlying administrator do not create independent Check Point login allowances.

A deliberate shared-key setup is also supported: leave the separate-key option off and enter the credential in API key. Naradox uses it for both read and write credentials, subject to that Check Point administrator's actual permissions. The form starts in this shared mode, so choose it deliberately. Continue with the trust settings before creating the instance.

3. Choose TLS trust and retain the request limits

The new-instance form starts with Verify TLS certificate off. Review this setting explicitly. Prefer enabling verification with a certificate trusted by the Naradox API runtime.

• System trust: enable Verify TLS certificate and leave Custom CA bundle path (optional) empty when the runtime already trusts the certificate issuer.
• Private CA: have the deployment administrator make the appropriate CA bundle available inside the Naradox API container, then enable verification and enter that container path. A path on your workstation or only on the host is insufficient. This bundle establishes trust in the Management server certificate; it is not an API-user certificate.
• Verification off: this is supported for self-signed certificates or private PKI unavailable to the runtime. Record the accepted loss of certificate verification and use appropriate management-network and egress controls. The inventory shows Verification off.

Under API request limits, start with Fixed concurrency 3 and API max RPS of 10 for a new Management target. Instances pointing at the same Management URL and domain share one policy. A new instance for an existing target inherits that policy; coordinate changes with its other users. These settings do not increase Check Point's own capacity or login allowances.

Leave Enable auto-install off. Install targets are optional for this read check; configure them in step 6 if policy installation belongs to your pilot.

4. Save and confirm the connection result

1. Choose Create instance. The page saves the instance and starts a connection check.
2. Wait for Checking to finish. Confirm Success, the Last checked time, and the reported API version for the intended instance.
3. Use that instance's Check connection action when you need a fresh result, including after resolving a connection problem.

Expected result: Naradox can reach and authenticate to the selected Management target with its view credential and confirm API support. This does not prove write permission, access to every rule or object, log readiness, installation targets, or gateway connectivity.

The inventory retains the last checked result. For management users, opening or changing the visible list can refresh missing or stale checks and reuse recent results; it does not continuously monitor the connection. View-only users see the saved result. If a check is Unconfirmed, an older timestamp or version is previous evidence, not a fresh success. Resolve the reported problem and request a new check.

5. Verify the published policy context

1. Open Rulebase with an authorized account and select the new connector instance.
2. Select the intended policy package and policy type. For Access Control, Threat Prevention, and HTTPS Inspection, select the layer explicitly. NAT uses the package without a layer selection.
3. Find an agreed existing rule. Confirm its name, source, destination, service, and action against the published policy you intend to manage.
4. After a change is published outside Naradox, use Refresh and wait for the read to complete before reviewing or editing that rule.

Naradox reads published Management state. Private, unpublished SmartConsole edits are not part of that view. Publishing commits the Management change; Install Policy is a separate operation that deploys policy to gateways or clusters.

If the pilot needs logs, have the Check Point administrator enable Log Indexingand run Install Database on the Management/Log Server. Naradox uses indexed logs; events in SmartConsole's raw Latest Log File view do not prove that this source is ready. Follow Logs and Watchlist to check the required access and inspect measurements, or use log troubleshooting for a failed read.

6. Prepare a manually controlled first change

Keep Enable auto-install off for the first workflow. Configure the Linux team's access and the independent Security reviewers using Access and permissions, then follow Request and approve a change. That controlled change validates the write and approval path separately from the connection check.

If your pilot includes installation, edit the connected instance and select the intended Install targets. Specific gateway and cluster suggestions become available after a successful connection. The built-in Policy Targets option is available even during creation; select it only when the package's configured policy targets are intended. Default targets apply to every package without its own target mapping. Saving these settings does not install policy or enable auto-install.

Have the authorized firewall administrator review the package and targets, request any agreed installation, and follow its separate result. See the policy-installation prerequisites.

Before enabling auto-install later

Validate it in staging with a working write key and exact package/target configuration. The Default policy package supplies context for instance-wide object publications; it does not choose a package for rule browsing. Keep Don't install when changes were published outside Naradox enabled and establish a reviewed successful installation baseline for both Access Control and Threat Prevention on the same configured targets. Missing baseline evidence, external publications, or unverifiable history can require manual installation.

Follow the release's bundled docs/GO_LIVE_RUNBOOK.md vendor-acceptance procedure before enabling this in production. A published change and a successful installation remain separate outcomes, including when auto-install is enabled.

Resolve a connection problem before widening access

• Failed or unconfirmed connection: check the Management URL, network reachability from the Naradox API service, domain, view credential, TLS trust, and API v2.1 support. Retain the visible error and time, correct the cause, then use Check connection.
• Success, but the expected rules are unavailable: verify the selected instance, package, policy type, and layer. Check both the Check Point administrator's access and the Naradox user's role, grant, or team scope.
• Read works, but a change fails: check the configured write credential and the user's current authority. Follow the existing request or job to its outcome; a connection check does not determine whether an uncertain write took effect.
• Rate limiting or a busy check: allow the reported wait and coordinate with other users of the same Management target. Avoid repeated clicks or additional connector instances as a workaround.

Continue with connector troubleshooting or change recovery. For support, provide the versions, affected step, time, and sanitized error using the support-request checklist; omit API keys and session material.

Maintain credentials and targets deliberately

To rotate a directly stored credential, edit the instance, replace the intended key, and choose Save changes. Leaving a masked credential unchanged preserves it; clearing its field removes it. Confirm the new connection result for a view key, and validate a changed write key through an agreed controlled workflow before relying on it for production changes.

For runtime secret references, follow Runtime connector secrets in your installation's docs/INSTALL_ADMIN.md. The deployment administrator must provision and authorize each reference for its exact instance, credential field, and target. That guide owns the supported environment update and API-service recreation procedure.

Changing the Management target or TLS trust can require explicitly resupplying credentials. Read the form's confirmation before saving. Repointing or deleting an instance also affects its dependent access and workflows: active work or dependencies can block it, and an allowed target change retires pending or approved rule requests. Plan this as a configuration change; do not delete and recreate an instance to recover an ordinary connection failure.