SailPoint Identity Security Cloud (ISC) is a SaaS platform. Active Directory is not. Neither is the HR database in your data centre, the Oracle instance behind three firewalls, or the file share nobody has touched since 2019. Something has to stand between the cloud tenant and all of that — and that something is the Virtual Appliance.
Quick answer: A Virtual Appliance (VA) in SailPoint Identity Security Cloud is a Linux-based virtual machine that you deploy inside your own network so the ISC cloud tenant can securely reach on-premises systems such as Active Directory, databases and internal applications. SailPoint supplies the VA as a virtual disk image and maintains, patches and upgrades its software; your organisation supplies the hypervisor and the network path. Crucially, the VA only ever makes outbound calls to SailPoint's cloud, so no inbound firewall ports are opened.
This guide walks through the VA the way an implementation team meets it: what it is, why the architecture works this way, what it needs to run, how it is deployed, what runs inside it when things break, and how it differs from IQService and from SailPoint IdentityIQ's on-premises model. If you are preparing for interviews, the companion SailPoint ISC interview questions post covers the VA as a set of question-and-answer pairs — this post is the architecture underneath those answers.
What is a Virtual Appliance in SailPoint ISC?
A Virtual Appliance in SailPoint Identity Security Cloud is a Linux-based virtual machine, supplied by SailPoint as a virtual disk image, that runs inside your network and connects your ISC tenant to sources and applications using SailPoint APIs, connectors and integrations. SailPoint's product documentation, checked September 2026, states that each VA is deployed on your infrastructure but managed by SailPoint, which maintains, patches and upgrades the VA software.
Three details surprise people the first time they meet a VA, and all three are worth remembering because they explain a lot of later behaviour:
It is a black box on purpose
The VA runs Flatcar Linux. Adding users, root access and trust/key store access are not supported. You own the virtual machine; SailPoint owns what runs on it.
It always runs in UTC
SailPoint Virtual Appliances run with UTC as their time zone and it cannot be changed. Scheduling is driven by the time zone you set on the cluster, not on the appliance.
"On-premises" includes your cloud
SailPoint treats private cloud applications reserved for your organisation as on-premises. A system in your own AWS VPC is still behind your perimeter and still typically needs a VA.
Why does SailPoint Identity Security Cloud need a Virtual Appliance?
SailPoint Identity Security Cloud needs a Virtual Appliance because SailPoint never connects inward to your network — instead each VA makes continuous outbound-only calls to SailPoint's cloud to poll a cluster queue for work such as data aggregation and access provisioning. That inversion is the whole security argument, and it is why network and security teams approve the model.
In a naive design, a SaaS identity platform would need firewall rules allowing SailPoint's cloud to reach your domain controllers. No security team would sign that off. The VA flips the direction of travel: the appliance sits inside the perimeter, reaches out over HTTPS, asks "is there anything for me to do?", does it locally against Active Directory or the database, and reports the result back out. Nothing is ever allowed in.
ISC tenant
Queues aggregation and provisioning work for the cluster
polls out
Virtual Appliance
Linux VM in your network; runs the connector locally
Your sources
Active Directory, JDBC databases, internal apps
Outbound-only data flow between a SailPoint Identity Security Cloud tenant, a Virtual Appliance and on-premises sources, per SailPoint documentation, September 2026.
This also answers a question that trips up candidates: not every source needs a VA. SailPoint ISC distinguishes VA-based connectors, which require a virtual appliance cluster, from SaaS-based connectors, which reach the target service directly over the internet and need no appliance at all. Working out which bucket a source falls into is a real design decision, and it is the cloud-era version of the direct-connect versus datafile choice covered in our guide to SailPoint IIQ connectors.
What are the system and network requirements for a SailPoint VA?
SailPoint's published Virtual Appliance requirements, checked September 2026, are a 4-core processor minimum with 8 cores recommended, 8 GB RAM minimum with 16 GB recommended, and at least 50 GB of free disk space per appliance. On the network side the VA needs outbound HTTPS on port 443 to SailPoint's cloud, plus outbound port 123 for NTP unless you point it at an internal time server.
| Requirement | SailPoint's published figure | What it means in practice |
|---|---|---|
| Processor | 4 cores minimum, 8 recommended | Under-provisioning is one of the most common causes of VA services failing to deploy |
| Memory | 8 GB minimum, 16 GB recommended | Large aggregations are memory-hungry; the recommended figure is the realistic one for production |
| Disk | 50 GB free minimum | Holds the appliance image, services and logs between rolling updates |
| Outbound HTTPS | Port 443 | The only path to SailPoint's cloud. No inbound rules are required |
| Time sync | Port 123 (NTP), outbound by default | Can be redirected to an internal NTP server if port 123 is not permitted outbound |
| Networking mode | Static network for local deployments | vSphere and Hyper-V deployments require a static configuration, not DHCP |
System and network requirements as published in SailPoint's Identity Security Cloud documentation (documentation.sailpoint.com), checked September 2026. SailPoint revises these requirements without notice — always confirm against the official page before sizing a production environment. SailPoint Academy is an independent training provider and is not affiliated with, authorised by or endorsed by SailPoint Technologies, Inc.
How is a SailPoint ISC Virtual Appliance deployed?
Deploying a SailPoint Identity Security Cloud Virtual Appliance means creating a VA cluster in the tenant, choosing a platform, deploying SailPoint's virtual disk image on a correctly sized virtual machine, pairing it to the tenant, selecting a network configuration, and waiting for the status to change to Connected. SailPoint's documentation notes that configuration takes roughly 30 minutes to finish.
The supported platforms are VMware vSphere and Microsoft Hyper-V for local deployments, and AWS (via a SailPoint AMI), Microsoft Azure and Google Cloud Platform for cloud deployments. The sequence looks like this:
- Create the cluster in ISC. Give it a unique name, a description and a time zone — that time zone sets the GMT offset used when scheduling account and entitlement aggregations for its sources.
- Pick the platform. vSphere, Hyper-V, AWS, Azure or GCP. Local deployments require static networking.
- Size and deploy the virtual machine against the requirements above, keeping a 1:1 ratio of virtual appliance to virtual machine.
- Pair the appliance to the tenant using the configuration values the tenant generates for that cluster.
- Choose the network mode — Standard, HTTP Proxy or Network Tunnel (covered below).
- Wait for "Connected". The appliance pulls down its services and registers itself; allow around 30 minutes.
- Deploy the second appliance into the same cluster, then monitor VA health and version status from there on.
One decision you cannot undo later
SailPoint does not support migrating an existing Virtual Appliance from one deployment method to another — moving from a standard deployment to a network-tunnel deployment, or from on-premises to cloud, means building new VAs. Choosing the deployment model is therefore a design decision, not a setting, and interviewers like asking about it precisely because it punishes guesswork.
Reading about a VA is not the same as pairing one
Attend a free 60-minute live demo before you decide — no payment, no commitment. Meet the trainer, see how the hands-on labs are structured, and ask exactly what you will build yourself.
What is a VA cluster, and how many appliances do you need?
A VA cluster is the logical group that sources are assigned to, and SailPoint requires at least two Virtual Appliances per cluster so connectivity to those sources survives updates. Because SailPoint applies updates as rolling reboots one appliance at a time, a single-appliance cluster goes dark every time a new image is pushed. Sources are attached to the cluster, never to an individual VA.
SailPoint's stated best practices go further: keep a 1:1 ratio of virtual appliance to virtual machine so one failed host cannot take out two appliances, run local VAs in the same cluster on different physical servers wherever possible, spread cloud VAs across different Availability Zones, and locate clusters close to the source systems they talk to. Each cluster is also given a type — Standard for most organisations, or IAI Harvester where an IdentityIQ estate is feeding AI-Driven Identity Security.
Alongside the cluster decision sits the network-mode decision, which is one of the more frequently debated topics on the SailPoint Developer Community:
| Network mode | What it does | When it is chosen |
|---|---|---|
| Standard | Uses the VA's normal outbound traffic to SailPoint endpoints | The default for most environments; simplest to operate |
| HTTP Proxy | Routes all HTTP/HTTPS traffic through an existing corporate proxy | Where egress must pass through a proxy for inspection or policy |
| Network Tunnel | Limits the outbound connections the VA generates | SailPoint's guidance: choose this only if your firewall cannot support host names |
Two optional layers sit on top: TLS encryption between the VA and sources that support it, which SailPoint recommends enabling, and the password interceptor, which catches password changes made directly in Active Directory and propagates them into ISC.
What runs inside a VA, and how do practitioners troubleshoot one?
The service practitioners name most often is the Cloud Connector Gateway (CCG), which processes source communication requests through the Virtual Appliance — if CCG is not running, Test Connection, aggregation and provisioning all fail even though the appliance itself looks alive. Alongside it sit the VA agent and the Charon service, plus a tunnel process on network-tunnel deployments.
The Cloud Connector Gateway executes connector operations. On the SailPoint Developer Community, "CCG not installed after VA pairing" and "CCG service does not start up on the VA" are recurring threads, with reported causes including an under-resourced appliance and a mismatch between the stored image and the image CCG tries to use.
The VA agent and Charon handle registration, configuration and lifecycle management against the tenant. After a fresh pairing it is normal to see the agent and Charon appear before CCG does — but not for CCG to still be missing a day later.
On network-tunnel deployments an additional tunnel process must come up after every reboot. "Tunnel process not starting after reboot of the VA" is a documented community thread, and it is the reason tunnel mode carries more operational overhead than standard mode.
SailPoint's own first-line guidance is refreshingly blunt: restarting the VA cluster is almost always the best first action to resolve problems with a VA, and if the problem cannot be resolved, standing up a replacement appliance is a supported answer rather than an admission of defeat. That disposability is the design intent — the VA holds no unique state, so rebuilding one costs an hour, not a weekend.
The community engagement numbers tell you how real this is. The Developer Community thread "Not able to connect to a VA" has accumulated 14 replies and around 2,298 views since March 2024, and "Virtual Appliance Secure Tunnel Configuration" around 1,411 views — for a component that, on paper, is just a virtual machine you switch on.
How do SailPoint Virtual Appliance updates work?
SailPoint pushes new Virtual Appliance images to the cluster, which then performs rolling updates and reboots on its appliances one at a time, so a cluster with two or more VAs keeps full availability throughout. This is the concrete reason behind the two-appliance minimum, and it is the answer interviewers are listening for when they ask why one VA is not enough.
Two operational consequences follow. First, long-running work can be caught by an update: aggregations that have not completed before an appliance is taken down for its reboot may be interrupted, which matters when a large Active Directory aggregation runs for hours. Second, appliances drift — a VA reporting an older image version than its cluster is a classic support case, and SailPoint sends an explicit "Virtual Appliance Out of Date" notification for exactly this.
Manual updates are available as a setting, but SailPoint notes that opting out of automatic Virtual Appliance updates requires additional legal documentation and a conversation with your Customer Success Manager. In other words: automatic updates are the expected path, and "we will patch it ourselves on our own schedule" is not really on the menu.
Virtual Appliance vs IQService vs IdentityIQ: what is the difference?
A Virtual Appliance is the Linux connectivity layer for SailPoint Identity Security Cloud; IQService is a Windows .NET agent used for provisioning to Windows targets; and IdentityIQ's application server is the full on-premises product, not a gateway. They are three different things that all live inside the customer's network, which is exactly why they get confused.
| Component | What it is | Where it fits |
|---|---|---|
| Virtual Appliance (VA) | SailPoint-supplied Linux VM acting as an outbound-only gateway | Identity Security Cloud only. Runs connectors locally on behalf of the cloud tenant |
| IQService | Windows-based .NET agent | Used by both IdentityIQ and ISC to provision into Active Directory and other Windows-API targets |
| IIQ application server | The IdentityIQ product itself, on a Java application server with its own database | IdentityIQ only. It is the platform, not a bridge to one |
The IQService point is the one worth memorising, because it is counter-intuitive: moving to the cloud does not remove the Windows agent. Provisioning from ISC into Active Directory still goes VA → IQService → AD, because some Windows operations require a Windows-native API. A candidate who says "ISC is SaaS so IQService is gone" has just revealed they have not implemented it.
If you are weighing which platform to learn first, the platform-level comparison lives in SailPoint IdentityIQ vs IdentityNow, and the equivalent on-premises picture — application server, database, task scheduler, Identity Cube — is broken down in SailPoint IIQ architecture explained. In SailPoint Academy's 14-module IIQ curriculum, that ground is Module 2, SailPoint Architecture — and understanding it first is what makes the VA feel obvious rather than mysterious.
Do SailPoint jobs in India actually ask for Virtual Appliance skills?
Yes — Virtual Appliance administration appears routinely in SailPoint Identity Security Cloud job descriptions in India, alongside identity profiles, source onboarding, transforms, provisioning policies, certification campaigns and REST API work. On 9 July 2026, Naukri listed 904 ISC-tagged openings across India, led by Bengaluru (around 314), Delhi NCR (around 197) and Hyderabad (around 136).
The employers are the familiar three groups: global consultancies (Deloitte, EY, PwC, Accenture, KPMG), IT services majors (TCS, Infosys, Wipro, Cognizant, HCLTech, Capgemini), and specialist identity firms. Most ISC job descriptions ask for roughly 2–8 years of IT experience plus working knowledge of Active Directory or Entra ID — the fuller picture is in our breakdown of SailPoint ISC jobs in India, and the long-run role progression is mapped on the IAM career path page.
Job counts are dated observations from public listings (Naukri, 9 July 2026) and change daily. These are market observations, not guarantees — hiring outcomes depend on prior experience, employer and interview performance. Employer names are used descriptively to identify publicly advertised roles; SailPoint Academy is not affiliated with, endorsed by or sponsored by these companies.
The honest problem with learning the VA on your own
Here is the gap nobody selling a course likes to mention: you cannot fully rehearse a VA deployment from documentation, because pairing an appliance requires a real ISC tenant and SailPoint does not offer a free public one. This is the same obstacle we describe in how to learn SailPoint ISC — and it is why so much VA knowledge circulates as community forum threads rather than tutorials.
What you can build alone is everything surrounding it: deploying Linux virtual machines on vSphere, Hyper-V or a cloud provider, configuring static networking, proving outbound HTTPS works through a corporate proxy, and reading service logs without panicking. Those are real, transferable skills, and they are what separates a candidate who can discuss a VA from one who has only read about it. SailPoint Academy runs a live online SailPoint ISC course covering Identity Security Cloud with hands-on labs, and a two-month live online SailPoint IIQ course at Rs. 25,000 with batches capped at 25, both led by a trainer with 14+ years of enterprise IAM experience. A free 60-minute demo comes first, so you can ask exactly what the labs cover before paying anything. What every provider awards at the end, ours included, is a SailPoint Academy certificate of completion — official SailPoint certification comes only from SailPoint's own Identity University.
Frequently Asked Questions
Learn the Layer Under the Interview Questions
Live online SailPoint training with hands-on labs, batches capped at 25, session recordings in the LMS, and a trainer with 14+ years of enterprise IAM experience. Attend a free 60-minute demo first. No payment. No commitment.