Defense & intelligence · Managed platform (Zscaler)

Zero Trust "Black Cloud" Overlay

Take mission applications off the public internet and grant access one user and one application at a time

Book a demonstrationRequest a technical briefingFactsheet

Overview

What you are buying

The Zero Trust "Black Cloud" Overlay is a managed service built on Zscaler Private Access. Moraph licenses, designs, configures and operates it so that your applications make only outbound connections and have no inbound listening ports or public IP addresses for an attacker to find. Access is decided per user, per device and per application by policy your organization approves, and every decision is logged for your security team and assessors.

The problem it solves

Many mission and business applications are still reached through VPN concentrators and firewall rules that expose an address and an open port to the internet. Once an attacker or a compromised device is on the network, the same flat access that lets staff reach their applications lets the attacker map and probe everything else. Programs are directed to move to zero trust, but the work of segmenting applications, rewriting access rules around identity and keeping the evidence for assessors falls on teams already running operations.

  • Applications are reachable on public or network-wide addresses and can be discovered by scanning
  • VPN access places users on a network rather than giving them a single application
  • Access rules are written around IP addresses rather than people, devices and missions
  • Evidence that access is limited and reviewed is hard to produce for assessors

Who uses it

  • Defense and intelligence program offices moving applications to zero trust access
  • Information system security managers and officers responsible for authorization evidence
  • Network and security operations teams who run remote and site access today
  • Mission application owners who need their systems reachable only by the people who use them
  • Assessors and inspectors who review access controls and logs

Requirements it supports

Executive Order 14028, Improving the Nation's CybersecurityOMB Memorandum M-22-09, Moving the U.S. Government Toward Zero Trust Cybersecurity PrinciplesDoD Zero Trust Strategy and Zero Trust Reference ArchitectureNIST SP 800-207, Zero Trust ArchitectureNIST SP 800-53 Rev. 5, Security and Privacy ControlsDoD Instruction 8510.01, Risk Management Framework for DoD Systems

The product supports these requirements; meeting them remains your organization’s responsibility.

Responsibilities

Who is responsible for what

Zscaler provides and operates the platform, Moraph designs, configures and runs it for you, and your organization owns the access decisions and the authorization of your systems.

AreaMoraphZscalerYour organization
LicensingResells and manages Zscaler subscriptions sized to your users and applicationsSets the license terms and subscription editionsApproves the order and accepts the vendor's terms
Platform availabilityMonitors the service and raises cases with Zscaler on your behalfOperates its cloud, service edges and their availability under its own service commitmentsTells Moraph about mission periods when changes should be frozen
Architecture and configurationDesigns segments, App Connector placement and access policies, and maintains the approved configuration baselineProvides the platform's configuration capabilitiesApproves the design and the baseline
Identity and accessIntegrates your identity provider and maps groups to access policiesEnforces the policies at the platformOwns identities, group membership and who is entitled to which application
App ConnectorsDeploys, patches and monitors connectors in your environmentsPublishes connector software and updatesProvides hosts, network paths and change windows
Monitoring and alert triageWatches connector health, policy denials and unusual access, and triages alertsProvides logs and platform statusYour security operations team decides on incidents and response
Incident responseContains issues within the overlay under your runbook and supports your investigationHandles incidents in its own platform and informs customers under its termsLeads the incident, notifies your authorities and decides on actions
ChangesRaises, tests and applies change requests through your change processChanges its own platform under its release practicesApproves policy and architecture changes
Authorization supportMaps controls, maintains the system documentation it is responsible for and supplies evidenceMaintains its own platform authorizations and evidenceOwns the authorization decision through your authorizing official
User supportSecond-line support for access and connector issuesThird-line support for platform defects through MoraphFirst-line help desk for your users

See how it works

A short walkthrough

Illustrative screens of how Moraph runs the service, with fictional sample data. They are not screens of Zscaler itself, which belongs to its vendor.

  1. Step 1

    The onboarding tracker

    Each application moves behind the overlay in a planned wave, with its connectors, policy approval and exposure removal tracked.

    ApplicationWaveConnectorsPolicyInbound exposureStatus
    Logistics Portal (fictional)12 of 2 healthyApprovedRemovedLive
    Maintenance Records (fictional)12 of 2 healthyApprovedRule still openAwaiting network team
    Training Scheduler (fictional)22 of 2 healthyApprovedOpen until cutoverPilot users
    Supply Request App (fictional)20 of 2DraftOpenConnectors pending
    Facilities Ticketing (fictional)3Not startedNot startedOpenDiscovery
    Each application moves behind the overlay in a planned wave, with its connectors, policy approval and exposure removal tracked.

  2. Step 2

    The configuration baseline

    Moraph compares the live configuration with the approved baseline and reports every difference for a decision.

    Example Command overlay · Baseline v14 (fictional)

    Baseline approved by
    ISSM (fictional role holder)
    Segments
    18
    Access policies
    42
    App Connector groups
    7
    Differences found
    2

    Differences to resolve

    • Policy for Training Scheduler allows a pilot group not in the baseline
    • Connector group West-2 running a version behind the baseline
    • No other differences
    Moraph compares the live configuration with the approved baseline and reports every difference for a decision.

  3. Step 3

    A change request

    Policy changes are raised with the reason and the difference, approved through your process, and recorded when applied.

    CR-1187 · Add Maintenance Planners group to Maintenance Records

    1. Request raised with mission justificationApplication owner
    2. Policy difference drafted and reviewedMoraph platform engineer
    3. Change approvedISSM
    4. Applied in the agreed windowMoraph platform engineer
    5. Access confirmed by a test user and baseline updatedMoraph service manager
    Policy changes are raised with the reason and the difference, approved through your process, and recorded when applied.

  4. Step 4

    Alert triage

    Moraph's operations team works alerts from connector health and access logs, and escalates what needs your security team.

    AlertSourceDescriptionSeverityOwnerStatus
    AT-5521Access logsRepeated denials for User 3307 across 6 applicationsHighMoraph operationsEscalated to SOC
    AT-5519ConnectorConnector West-2-b not reportingMediumMoraph operationsIn progress
    AT-5514Access logsSign-in from unmanaged device blocked by posture checkLowMoraph operationsClosed, expected behavior
    AT-5508PlatformVendor service notice for one regionMediumMoraph service managerMonitoring
    Moraph's operations team works alerts from connector health and access logs, and escalates what needs your security team.

  5. Step 5

    The access review

    Application owners certify who can reach their application, and removals are tracked until they are applied.

    ApplicationOwnerGroupsUsersRemovals requestedStatus
    Logistics Portal (fictional)Application owner A32124Certified
    Maintenance Records (fictional)Application owner B2960Certified
    Training Scheduler (fictional)Application owner C135-Overdue
    Supply Request App (fictional)Application owner D21402In review
    Application owners certify who can reach their application, and removals are tracked until they are applied.

  6. Step 6

    The monthly service review

    Each month Moraph reviews the service with you: onboarding progress, changes, alerts, vendor notices and open actions.

    Monthly service review · Example Command (fictional)

    Applications live
    11 of 26
    Changes applied
    14
    Alerts escalated to SOC
    3
    Baseline differences open
    2
    Vendor cases open
    1

    Actions agreed

    • Network team to remove remaining inbound rule for Maintenance Records
    • Application owner C to complete overdue access review
    • Moraph to upgrade connector group West-2 in next window
    Each month Moraph reviews the service with you: onboarding progress, changes, alerts, vendor notices and open actions.

Workflows

The principal workflows

  1. Onboard an application

    Each application is moved behind the overlay in a planned sequence: Moraph places App Connectors next to it, defines it as a segment, and writes the access policy your application owner approves.

    • Application owner requests onboarding and names the user groups who need it
    • Moraph records the application's hosts, ports and dependencies
    • App Connectors are deployed in the application's environment with outbound-only connections
    • Segment and access policy drafted and approved by the application owner and ISSM
    • Users tested, then inbound firewall rules and public addresses removed by your network team

  2. Grant and review access

    Zscaler evaluates each connection against the user's identity, group and device posture before brokering it to one application. Moraph keeps the policies aligned to the groups your identity team manages and runs periodic access reviews.

    • User signs in through your identity provider
    • Zscaler checks identity, group and device posture against the policy
    • Connection brokered to the single application allowed, never to the network
    • Denied attempts logged with the reason
    • Access lists exported for application owners to certify on your review cycle

  3. Monitor and respond

    Connector health, policy denials and unusual access are streamed to your SIEM and watched by Moraph's operations team, who triage alerts and hand confirmed incidents to your security operations team.

    • Access and connector logs streamed to your SIEM
    • Moraph operations triages alerts against agreed runbooks
    • Confirmed issues escalated to your security operations team with evidence
    • Containment actions in the overlay taken only as your runbook authorizes
    • Each alert closed with its outcome recorded

  4. Change and evidence

    Every change to segments, policies or connectors goes through your change process against an approved configuration baseline, and the resulting records feed your authorization package and continuous monitoring.

    • Change request raised with the reason and the policy difference
    • Change tested in a staging policy set where one exists
    • Application owner or ISSM approves
    • Moraph applies the change and confirms the result
    • Baseline and evidence records updated for continuous monitoring

Roles and permissions

Who does what in the product

Each role below is a starting point. During implementation we set them up to match your teams, and every action anyone takes is recorded in the audit trail.

Application owner

System owner, mission application owner, program office technical lead

Decides who should reach their application and approves the access policy that enforces it.

Sees

  • Their application's onboarding status, segment and policy
  • Who can reach the application and recent access decisions
  • Access reviews for their application
  • Change requests affecting their application

Does

  • Requests onboarding and names the user groups who need access
  • Approves or returns access policy drafts
  • Certifies access lists during reviews and requests removals
  • Raises change requests with the mission justification
  • Confirms the application works for test users before cutover

Cannot

  • Change policies directly in the platform
  • Approve changes to other owners' applications
  • Change the overall architecture or segmentation design
Approvals
Approves access policies and changes for their application; architecture-level changes also need the ISSM.
Notified about
Policy drafts waiting for approval, access reviews due, changes applied to their application, and alerts involving it.

ISSM or ISSO

Information system security manager, information system security officer, cybersecurity lead

Owns the security posture and authorization evidence of the overlay and approves its design and baseline.

Sees

  • The architecture, configuration baseline and every difference from it
  • All change requests and their approvals
  • Alert and incident records
  • Control mappings and evidence packages

Does

  • Approves the architecture and the configuration baseline
  • Approves changes that affect segmentation, posture rules or administration
  • Reviews baseline differences and decides how they are resolved
  • Uses the evidence package in your authorization and continuous monitoring
  • Sets which alerts go straight to security operations

Cannot

  • Edit or delete audit records
  • Make changes in the platform without a recorded change
  • Waive another application owner's approval for their application
Approvals
Approves the baseline and architecture-level changes; their own change requests are approved by a second designated approver.
Notified about
Baseline differences found, changes waiting for approval, escalated alerts and vendor service notices.

Security operations

SOC analyst, cyber defense analyst, incident responder

Receives escalated alerts from the overlay and leads the response to any confirmed incident.

Sees

  • Access and connector logs in your SIEM
  • Alerts Moraph has escalated, with the evidence
  • Containment actions taken in the overlay

Does

  • Investigates escalated alerts
  • Decides on containment and response
  • Directs Moraph to take containment actions the runbook allows, such as suspending a user's access
  • Records the incident outcome

Cannot

  • Change access policies outside an approved emergency change
  • Change the configuration baseline
Approvals
Emergency containment actions are recorded and reviewed afterward by the ISSM through the change process.
Notified about
Alerts escalated by Moraph and vendor notices that affect security.

Moraph service manager

Moraph service delivery manager

Runs the managed service for you: onboarding plan, change process, vendor relationship and monthly service reviews.

Sees

  • The onboarding tracker, baseline and change records
  • Alert and incident records
  • Vendor cases and notices
  • License usage

Does

  • Plans onboarding waves with your program office
  • Coordinates change requests through your process
  • Manages Zscaler licensing and vendor cases
  • Runs monthly service reviews and tracks actions
  • Prepares reporting and evidence packages

Cannot

  • Approve changes on your behalf
  • Grant a user access without an approved policy
  • See your application data
Approvals
Their work is governed by the approvals of the application owner and ISSM; nothing in the service is self-approved.
Notified about
Changes approved or returned, escalated alerts, vendor notices and overdue actions.

Moraph platform engineer

Moraph zero trust engineer, network security engineer

Configures segments, policies and App Connectors and triages alerts, within the changes your organization approves.

Sees

  • Platform configuration within the service scope
  • Connector health and access logs needed for triage
  • Change requests assigned to them

Does

  • Drafts segments and access policies
  • Deploys, patches and monitors App Connectors
  • Applies approved changes and confirms the result
  • Triages alerts and escalates confirmed issues
  • Compares live configuration with the baseline

Cannot

  • Apply a change that has not been approved, except containment your runbook pre-authorizes
  • Approve their own change
  • Delete logs or audit records
Approvals
Every change they apply has a recorded approval from your organization.
Notified about
Changes approved for their window, connector failures and alerts assigned to them.

Help desk

Service desk analyst, IT support technician

Handles first-line user questions and passes access and connector issues to Moraph.

Sees

  • Whether a user's access attempt was allowed or denied, and the reason
  • Known service notices

Does

  • Answers user questions about signing in and the client
  • Raises tickets to Moraph for access or connector issues
  • Tells users how to request access through the application owner

Cannot

  • Grant or change access
  • See configuration beyond access decisions
Approvals
None; access requests are routed to application owners.
Notified about
Service notices and changes to their tickets.

Assessor or inspector (read-only)

Security control assessor, inspector general staff, internal auditor

Reviews the configuration, logs and evidence without being able to change anything.

Sees

  • Architecture, baseline and control mappings
  • Change, alert and access review records
  • Exports of access logs within the period granted

Does

  • Reads records within the scope granted
  • Exports evidence, with each export logged
  • Records review notes where enabled

Cannot

  • Change, approve or delete anything
  • Keep access after it expires
Approvals
Their access is approved by the ISSM with a scope and an end date.
Notified about
Nothing by default; access granted and expiring is confirmed to the ISSM.

Permissions at a glance

ActionApp ownerISSMSecurity opsMoraph SMMoraph engHelp deskAssessor
Request application onboardingOwn work onlyFullNo accessFullNo accessNo accessNo access
Approve an access policyApprovesApprovesNo accessNo accessNo accessNo accessNo access
Change access policies in the platformNo accessNo accessNo accessNo accessFullNo accessNo access
Approve architecture and baselineNo accessApprovesNo accessNo accessNo accessNo accessNo access
Deploy or update App ConnectorsNo accessNo accessNo accessNo accessFullNo accessNo access
Triage alertsNo accessView onlyFullView onlyFullNo accessNo access
Order containment of a user's accessNo accessApprovesFullNo accessNo accessNo accessNo access
Certify access reviewsOwn work onlyView onlyNo accessView onlyNo accessNo accessView only
View access decisionsOwn work onlyFullFullView onlyView onlyView onlyView only
Manage licenses and vendor casesNo accessView onlyNo accessFullNo accessNo accessNo access
View audit trail and evidenceNo accessView onlyView onlyView onlyNo accessNo accessView only
Manage administrator accountsNo accessApprovesNo accessFullNo accessNo accessNo access
  • Full
  • Own work only
  • Approves
  • View only
  • No access

How access is controlled

  • No one approves their own change: Moraph engineers apply only changes your organization has approved, and an ISSM's own change requests need a second designated approver.
  • Roles are agreed during implementation and can be limited by application, environment or site, so each application owner sees and approves only their own applications.
  • Moraph's administrative accounts are named, role-based and reviewed with you; tickets for defense clients are handled only by US citizens with active clearances.
  • Assessors and inspectors get temporary read-only access with a defined scope and an end date, rather than shared accounts.

Features

What it does

Applications hidden from the internet

Zscaler App Connectors make outbound connections to the Zscaler cloud, so protected applications need no inbound ports or public addresses.

Per-application access

Zscaler brokers each user to the specific applications their policy allows, rather than placing them on a network segment.

Identity-based policy

Access policies are written around groups from your identity provider, with Moraph keeping the mapping current as groups change.

Device posture checks

Policies can require device conditions such as a managed certificate or an approved client before access is granted.

Private Service Edge

Where your policy requires brokering inside your own environment, Moraph deploys and runs Zscaler Private Service Edges there.

Segmentation design

Moraph groups applications into segments by mission, sensitivity and user population, documented for your assessors.

Configuration baseline

An approved baseline of segments, policies and settings, compared against the live configuration on a schedule with differences reported.

Log streaming to your SIEM

Access and connector logs are streamed to the security information and event management system you already run.

Alert triage

Moraph's operations team watches connector health and unusual access and hands confirmed issues to your security team with the evidence.

Change control

Every policy and connector change is raised, approved through your process, applied and recorded against the baseline.

Access reviews

Lists of who can reach each application, prepared for application owners to certify, with removals tracked through to completion.

Authorization evidence

Control mappings, configuration records and logs packaged to support your organization's own authorization and continuous monitoring.

Integrations

How it connects to your systems

Connects toHowWhat flows
Identity providerUsers authenticate through your identity provider using SAML, with group membership supplied for policy decisions, including where your identity provider supports PKI and CAC-based sign-in.In: user identity and group membership.
User provisioningUsers and groups synchronized from your directory through SCIM where your identity provider supports it.In: users and groups.
SIEMZscaler log streaming sends access and connector events to your SIEM for correlation and retention under your policy.Out: access decisions, connector status and administrator activity.
Endpoint managementDevice posture checks draw on the certificates and client settings your endpoint management tool deploys.In: device posture signals checked at connection time.
IT service managementChange requests, incidents and service requests are raised and tracked in your service management tool, or in Moraph's if you have none.In and out: tickets, approvals and status.
Network and firewall teamsAfter each application is onboarded, your network team removes the inbound rules and public addresses it no longer needs, with Moraph supplying the list.Out: rules and addresses to retire, per application.
Compliance toolingControl mappings and evidence exported for your GRC or authorization tool.Out: control mappings, baseline records and review evidence.

Each integration is confirmed in discovery and specified in the design. See how an engagement progresses.

Security and privacy

How your data is protected

Single sign-on

Administrators and users sign in through your identity provider, so your authentication and multi-factor policies apply.

Least-privilege administration

Moraph administrators hold role-based rights in the Zscaler admin portal limited to the tasks in the service scope.

Cleared US support staff

Tickets for federal and defense clients are handled only by US citizens with active clearances.

Complete audit trail

Every administrative change and access decision is logged with the person and time and kept under your retention policy.

US hosting for government

Moraph's service tooling for US government clients is hosted in the United States region only.

People decide

Where automation suggests a policy change or flags an anomaly, a named person reviews it; nothing is applied without approval.

Company-wide controls, independent audits (SOC 2 Type II and ISO/IEC 27001) and data residency are described in our Trust Center, where you can request the evidence pack.

Reporting

What you can report on

11 standard reports, grouped by who uses them. Each shows who it is for, how it can be broken down, how it is delivered and what it is used for. The data behind them is also available to your own reporting tools.

Service operations

Onboarding progress

For program office and ISSM

Every application in scope with its wave, connector status, policy approval and whether its inbound exposure has been removed.

Break down by
Wave, Environment, Application owner, Status
Delivered as
Live view; monthly service review pack; CSV export
Used for
Tracking the move to zero trust access and the exposure still to remove.

Connector health

For moraph operations and your network team

Status, version and capacity of each App Connector group and any Private Service Edges.

Break down by
Environment, Connector group, Version, Status
Delivered as
Live view; monthly service review pack
Used for
Planning upgrades and capacity, and spotting connectors behind the baseline.

Alerts and outcomes

For security operations, ISSM, Moraph service manager

Alerts triaged, closed and escalated, with the outcome of each and the time it was handed over.

Break down by
Source, Severity, Outcome, Period
Delivered as
Live view; monthly service review pack; CSV export
Used for
Checking that alerts are worked and tuning which ones are escalated.

Access

Access decisions by application

For application owners and ISSM

Allowed and denied access attempts for each application, with the policy and reason behind each denial.

Break down by
Application, User group, Decision, Reason, Period
Delivered as
Live view; CSV export; streamed to your SIEM
Used for
Confirming policies match how the application is used and investigating unexpected denials.

Access review status

For iSSM and application owners

Each application's latest review, who certified it, removals requested and whether they have been applied.

Break down by
Application, Owner, Review cycle, Status
Delivered as
Live view; scheduled email; PDF export
Used for
Showing that access is reviewed and that removals are completed.

Posture check results

For iSSM and endpoint team

Connections blocked or allowed by device posture rules, by rule and device type.

Break down by
Posture rule, Device type, Decision, Period
Delivered as
Live view; CSV export
Used for
Finding devices that fall outside policy and checking rules before they are tightened.

Change and configuration

Baseline comparison

For iSSM and Moraph service manager

Differences between the live configuration and the approved baseline, with how each was resolved.

Break down by
Object type, Difference type, Resolution, Date
Delivered as
Scheduled run; PDF and CSV export
Used for
Evidence for continuous monitoring that the configuration stays as approved.

Change history

For iSSM, assessors

Every change with its request, approval, implementer, time applied and the configuration difference.

Break down by
Application, Change type, Approver, Period
Delivered as
Live view; PDF and CSV export
Used for
Showing assessors that each change was requested, approved and recorded.

Assurance

Control evidence package

For iSSM and assessors

Control mappings for the overlay with the configuration records, reviews and logs that support each control Moraph is responsible for.

Break down by
Control family, Responsibility, Evidence type
Delivered as
On request; PDF and CSV export
Used for
Supporting your organization's authorization and continuous monitoring.

Administrator activity

For iSSM and assessors

Every action taken by Moraph and client administrators in the platform, with the person, time and related change.

Break down by
Administrator, Action, Change reference, Date range
Delivered as
Live view; CSV export; streamed to your SIEM
Used for
Reviewing privileged activity and matching it to approved changes.

Monthly service review pack

For program office, ISSM, Moraph service manager

Onboarding progress, changes, alerts, vendor notices, license usage and open actions for the month.

Break down by
Period, Environment
Delivered as
PDF; scheduled email
Used for
Running the monthly service review and recording the actions agreed.

Exports, access and evidence

  • Reports can be exported to CSV and evidence reports to PDF, and scheduled to arrive by email for the people entitled to see them.
  • Access, connector and administrator logs are streamed to your SIEM, so your own security tooling holds the primary record under your retention policy.
  • Reports respect each viewer's role: an application owner sees their own applications, the ISSM sees the whole overlay, and assessors get read-only access within a set scope.
  • Evidence reports can be run as of a past date and give the same result each time. Running and exporting a report is itself recorded.
  • Reports describe the service Moraph runs; Zscaler's own platform reporting remains available to your administrators under your license.

Deployment

Where and how it runs

Zscaler cloud with US-hosted management

Zscaler's government cloud offering where your requirements call for it, with Moraph's service tooling hosted in the United States region.

Private Service Edge in your environment

Brokering placed inside your data centers or enclaves where your policy requires traffic to stay within them.

Disconnected or classified environments

Where operations take place on classified networks, they are carried out under your organization's authority and procedures, by cleared staff, scoped in the proposal.

Security controls, independent audits and data residency are set out in our Trust Center. Engagement models and what drives a quotation are on Working with Moraph.

Implementation

What a rollout involves

The general phases are on Working with Moraph. For this product, they involve the following.

Discovery

We inventory the applications in scope, their users, hosts, ports and dependencies, and how they are reached today. We need application owners and your network team.

Architecture and design

We design segments, connector placement, policies and any Private Service Edges, and document the design for your ISSM.

Identity integration

Your identity provider and directory groups are connected, and groups are mapped to policies with your identity team.

Pilot

A small set of applications and users moves first, so access, posture checks and logging are proven before wider rollout.

Phased onboarding

Applications move in waves you approve, and after each wave your network team retires the inbound exposure it no longer needs.

Transition to operations

Runbooks, escalation paths, the configuration baseline and reporting are agreed, and the service moves into steady-state management.

Limitations

What it does not do

Worth knowing before you evaluate it.

  • Moraph is not Zscaler. Zscaler owns and operates the platform, and its own service commitments, roadmap and outages apply.
  • Licenses are subject to Zscaler's terms, which are passed through to your organization.
  • Moraph does not authorize your systems. Your authorizing official makes that decision; Moraph maps controls and supplies evidence to support it.
  • Hiding an application reduces its exposure but does not fix vulnerabilities inside it. Patching and hardening of the applications remain with their owners.
  • Some applications, such as those that depend on server-initiated connections to clients, may need redesign or another access method; these are identified during discovery.
  • Removing old firewall rules and public addresses is carried out by your network team; Moraph identifies them but does not change networks outside the service scope.
  • Who is entitled to which application is your decision. Moraph configures and reviews policies but does not grant access on its own judgment.
  • The service does not replace your security operations center; it supplies alerts and evidence to it.

Evaluation checklist

What to test in a demonstration or pilot

Questions worth putting to us, and to any other vendor you are considering.

  1. List the applications you would move first and check that each can work with outbound-only connectors
  2. Confirm your identity provider can supply the groups your access policies need
  3. Scan a pilot application from outside before and after onboarding and compare what is visible
  4. Review a sample configuration baseline and change record with your ISSM
  5. Agree with your security operations team which alerts Moraph triages and which come straight to them
  6. Read the responsibilities table against your existing support contracts and authorization boundary

Questions

Frequently asked questions

Do we buy Zscaler licenses from Moraph?

You can. Moraph resells Zscaler subscriptions as part of the service, under Zscaler's terms. If you already hold licenses, Moraph can manage them instead.

Is the overlay authorized for our networks?

Authorization is your authorizing official's decision. Moraph maps the service to your controls and supplies the evidence your authorization package needs; Zscaler maintains its own platform authorizations.

Can Moraph staff see our application data?

Moraph administers the access policies and connectors, not your applications. Administrative access is role-based, logged, and limited to cleared US staff for defense clients.

What happens if Zscaler has an outage?

Zscaler's own service commitments apply. Moraph monitors the service, raises cases with Zscaler, keeps you informed and runs any fallback procedures you have agreed in the runbook.

How is it priced?

Zscaler licenses at the vendor's pricing plus a managed service fee based on the users, applications and environments in scope, with implementation charged separately. See Working with Moraph for what drives a quotation.

Can we take the service back in-house later?

Yes. The configuration, baseline, runbooks and documentation are yours, and the transition is set out in the contract.

Next steps

Evaluate Zero Trust "Black Cloud" Overlay

Book a demonstration

See the product working with sample data, focused on your workflows.

Request a demonstration

Request a technical briefing

Architecture, integrations, security and hosting, with our engineers and your technical team.

Request a briefing

Factsheet

This page on two sides, to share with colleagues or add to your evaluation file.

Open the factsheet

Buying through a formal procurement? See How to buy for purchasing routes, accessibility conformance reports and company information. Documentation: Zero Trust "Black Cloud" Overlay guides on docs.moraph.com (getting started and security guides are public; setup, administration and integration guides are for client accounts). Support: Zero Trust "Black Cloud" Overlay support guide.

Related products