Bring Antara into the network you already run.

Start with a path and ownership inventory

List the applications that keep the organization working, then describe how people and services reach each one today. Record DNS, identity redirects, certificates, outbound proxies, inbound gateways, source-IP allowlists, and non-web dependencies. Include SaaS file transfers and third-party access, not just the primary login page. A useful inventory names an application owner and a network owner for every path.

Classify entry points into managed workforce devices, approved clientless users, branches, and cloud workloads. All managed workforce capabilities use Antara Secure Access. Existing UEM distributes that one client; Antara Admin governs which capabilities and policies apply to each cohort. A connector near an application is infrastructure, not another client the employee needs to install.

Enroll once, activate capabilities deliberately

Establish tenant and device enrollment before changing traffic handling. Test normal sign-in, lost credentials, certificate renewal, and the service-desk recovery process. Distribute the intended configuration through the existing endpoint-management workflow. Client installation, authentication, and route enforcement are separate rollout checkpoints even though they belong to one application.

Start with a narrow user cohort. Enable a known private application through ZTNA and the required VPN transport, then verify hybrid negotiation and certificate checks. Add internet steering for that cohort, followed by a small RBI destination set. Enable broader data policy after the actual business workflows and exception paths have been evaluated. The user keeps the same client throughout.

Publish resources with explicit dependencies

Place private application connectors near the origins they serve. Use separate failure domains so one host or availability zone cannot remove all access. Resolve the resource’s names from the intended network and publish only the required protocols and destinations. A private ERP may depend on a separate authentication endpoint, report server, or database; discover those dependencies before writing a broad network exception.

Treat overlapping address spaces and split DNS as first-class design inputs. Decide which resolver answers private names, which routes belong to the access client, and how IPv6 behaves. Test both successful application tasks and deliberate attempts to reach an unrelated resource. An application that works only after allowing an entire subnet has not yet demonstrated the intended least-privilege policy.

Add web, data, and isolation policy to the same client

Document the selection rules that send web traffic to Antara enforcement. Make proxy configuration, tunnel routing, bypass rules, and operating-system differences visible to both the endpoint and network teams. Prevent competing security agents or proxy settings from creating forwarding loops. Preserve an exception owner and expiry whenever compatibility requires a direct path.

For TLS inspection, distribute the required trust through managed channels and validate sensitive application categories with the appropriate owners. For RBI, test local input, rendering, authentication redirects, downloads, printing, and accessibility. For DLP, use representative approved test documents and record false-positive handling. The same policy should produce an attributable outcome in Antara Admin, not a generic connection failure.

Integrate SaaS or AI application governance using the interfaces the application actually exposes. Domain-level control, corporate-tenant restriction, inline transaction analysis, and API scanning are different controls. Write down which one covers each requirement. This avoids promising that a single allowlist entry can distinguish every action in every cloud application.

Connect sites without losing the security path

Retain the existing SD-WAN or routing service where it already provides the required underlay. Agree how branch traffic reaches Antara, where routing policy is authoritative, and what happens when the preferred link fails. Test DNS, long-lived sessions, asymmetric paths, NAT, and the impact of encapsulation on packet size. Branch failover is complete only when the alternate route still reaches the required enforcement.

Separate critical local communication from internet and private-cloud access. A manufacturing site may need local controls to remain available during WAN loss. That requirement should result in a documented local policy, not an accidental fail-open setting that grants broad corporate access. Workload traffic likewise needs service identity or a scoped network policy, rather than borrowing a user’s session.

Leave the pilot with a concrete acceptance contract

pilot:
  workforce_client: Antara Secure Access
  management: Antara Admin
  cohort: finance-pilot
  private_resource: finance-erp
  browsing: policy-selected-isolation
  branch_handoff: existing-sd-wan
  required_evidence:
    - identity-and-device-context
    - negotiated-cryptographic-profile
    - resource-and-data-policy-version
    - inspection-disposition
    - failover-and-revocation-results
  rollout:
    owner: network-security-team
    approval: required
    rollback: previous-approved-policy

This planning record gives the participating teams a common checklist. Translate it into supported configuration for the versions in the pilot; it is not a command to send to an undocumented endpoint. Close the pilot with task-level evidence, residual exceptions, and a named owner for rollback. Expansion should follow verified outcomes rather than the number of installed clients.