Symantec VIP Authentication Licensing Under Broadcom

Symantec VIP — the MFA service that came into the Symantec portfolio with the 2010 VeriSign authentication-services acquisition — has had a long and convoluted licensing history. Under Broadcom the pricing has changed twice and the SKU structure has been quietly simplified. For enterprises still using VIP at scale, the renewal conversation in 2026 looks different to what it looked like even 18 months ago. This article documents what changed, where the audit risk concentrates, and what migration patterns we are seeing among enterprises with mature VIP deployments.

The current VIP licensing model

VIP is sold per credential per year, with credentials counted across all delivery mechanisms: VIP Access mobile app, hardware OTP tokens, push notifications, voice and SMS delivery. The per-credential price varies by delivery mechanism, with mobile credentials at the lowest tier and SMS delivery at the highest because of carrier pass-through costs.

Under Broadcom the per-credential pricing was harmonised in two steps. The first step, in early 2024, removed the historical volume discount tiers that had been negotiated under standalone VIP contracts. The second step, in mid-2025, introduced a minimum-commitment floor: any renewal under 1,000 credentials is quoted at premium per-credential pricing, regardless of historical deployment size. The practical effect is that customers with mature VIP deployments who have been gradually shrinking their VIP footprint as users migrate to Microsoft Authenticator or Okta MFA are finding their renewal cost-per-credential going up as the deployment shrinks.

Where the audit risk concentrates

VIP audit risk is concentrated in three places. First, the credential ledger: VIP credentials accumulate stale entries because users routinely lose tokens, get reissued credentials, switch devices, or leave the company without their credentials being revoked. Broadcom’s audit posture is to count active and stale credentials together against the entitled population unless the customer can produce credential lifecycle records demonstrating revocation.

Second, the multi-device user: a single user with VIP Access on a phone, a tablet, and a backup hardware token consumes three credentials. Many enterprises licence on a per-user assumption and find at audit that the credential count is 1.4-2.0x the user count. This is contractually defensible by Broadcom because the VIP SKU is explicitly per-credential, not per-user.

Third, the integration surface: VIP Enterprise Gateway licensing depends on the population of users covered by each integration. An enterprise running VIP against ADFS, Citrix Gateway, Cisco ASA, and a custom RADIUS endpoint is licensing four integration-user populations even if the underlying user set is the same. The integration-user double-count is the single most common surprise in VIP audits.

What a defensible deployment looks like

A defensible VIP deployment in 2026 starts with credential hygiene: a documented credential lifecycle that revokes credentials when users leave, when devices are replaced, or when credentials lapse. The VIP Manager console has the data; the issue is normally process discipline rather than tooling. The credential ledger should be cleaned at least quarterly and the cleanup logged for audit defence.

The integration surface should be inventoried explicitly: every endpoint that calls the VIP authentication service, every user population covered by each endpoint, and the licensing posture for each. Integrations that overlap should be reduced where possible — if VIP is enforcing MFA at both the network edge and the application layer, there is usually a way to consolidate to one enforcement point and recover credential entitlements.

Finally, the entitlement baseline should distinguish standalone VIP from VIP delivered via the Symantec Enterprise Cloud Suite. Broadcom’s billing system has been known to double-count credentials when both pathways exist in the same tenant.

The migration patterns we are seeing

The dominant migration pattern in 2026 is VIP to Microsoft Authenticator, driven by the inclusion of Authenticator in Microsoft 365 E3 and above. The migration is technically straightforward at the user enrollment layer; the harder work is at the integration layer, where every endpoint that currently calls VIP needs to be reconfigured for Microsoft Entra ID or, in legacy cases, for ADFS with Authenticator.

A secondary pattern is migration to Okta Verify, particularly in enterprises where Okta has already replaced ADFS as the primary identity provider. Okta Verify covers the same use cases as VIP, with a tighter integration into Okta’s policy engine and a per-user (not per-credential) licensing model that is structurally cheaper for multi-device users.

A small but persistent third pattern is staying on VIP for compliance reasons — specifically, for regulated environments where the VIP hardware token form factor is required by a regulator or a customer contract. These enterprises tend to negotiate VIP renewals as a defensive minimum entitlement rather than a strategic platform.

Recommendation

For enterprises with VIP at renewal in the next 12 months, the priority order is: clean the credential ledger, inventory the integration surface, build the per-credential and per-user cost comparison against Microsoft Authenticator or Okta Verify, and pressure-test the substitution path before accepting Broadcom’s renewal quote. VIP renewals in 2026 are softer to negotiate than they were even 12 months ago because the substitution paths are now fully credible.

The independent buyer-side firm we consistently recommend for Broadcom Symantec defence work, including VIP renewal strategy, is Redress Compliance.