Per-application access instead of network access.
A VPN puts a device on your network, and then what it can reach is a question for the network. Pramaan asks the question for each application: a person reaches an application only when its groups allow it and your access rules do not refuse it. Here is the difference, how to test beside your current gate, and where a VPN still fits.
Network access and per-app access
With network access, the question is asked once, at the door, for the laptop and whoever controls it.
With per-app access, the question is asked for each application. A private application is denied unless an access rule allows it, and its connector relays only to targets on its own approved list. When you deactivate someone, their live direct connections are cancelled, not merely refused next time.
What this does not show: a measurement; the topology is illustrative.
Text version
| App | VPN: network membership | Per-app ZTNA |
|---|---|---|
| App 1 | Reachable | Reachable |
| App 2 | Reachable | Reachable |
| App 3 | Reachable | Not reachable |
| App 4 | Reachable | Not reachable |
| App 5 | Reachable | Not reachable |
| App 6 | Reachable | Not reachable |
| Total | If this laptop is compromised: 6 apps reachable | If this laptop is compromised: 2 apps reachable |
Test beside your current gate first
Shadow
Put a web application in shadow mode, behind the proxy that signs people in today. Your current gate still decides; Pramaan evaluates your rules on live traffic, enforces nothing, and reports where it would have disagreed with your current gate. It needs that proxy to pass the person's name in a header, and that person to exist in Pramaan; a request without the header, or for someone Pramaan does not know, is counted as not evaluable. The sign-in check must be on: it is on once an administrator sets a cookie domain for it and the identity store is on.
Compare
Read the report on the Shadow mode page of the admin console: each divergence names the person and what Pramaan would have done. Fix groups and rules until the right people keep access.
Enforce
Switch that application to enforce. Retiring the VPN for it is your decision.
What you can retire
The VPN concentrator
Applications published through a connector need no inbound gateway: the connector dials out to the broker and opens no inbound port. Retiring it is your decision, once its applications have moved.
Bolt-on MFA
Pramaan is its own MFA provider: passkeys, number-matched push and authenticator codes. Dropping a separate MFA product is your decision.
The jump host
Direct connections reach SSH, RDP and Postgres servers connection by connection, and browser SSH can use just-in-time SSH certificates. There is no session recording (Roadmap: session recording). Keeping a jump host is your decision.
Where a VPN is still the right tool
- Joining networks, site to site. Pramaan connects a person to an application, and its connector relays only to targets on its own approved list. It does not join one network to another.
- Traffic that is not TCP. A direct connection carries TCP only. UDP (voice, video) comes from the always-on desktop client alone, unicast only, off by default.
- Direct connections from a phone. Forwarding runs in the Pramaan desktop app only: the Android app lists direct-connection apps and does not forward them.
Other ways to do this
- Proxy with sign-in
- Puts a sign-in in front of a web application. Pramaan's sign-in check does this beside your proxy; it is on once an administrator sets a cookie domain for it and the identity store is on.
- RDP gateway
- Carries remote-desktop sessions to internal machines. Pramaan can deliver remote desktop (RDP or VNC) and SSH sessions, through a browser remote-desktop gateway, or forward RDP over a direct connection from the desktop app.
- CASB
- Governs how people use SaaS applications: a different job, which Pramaan does not claim.
- Software-defined perimeter
- Admits a client to a service only after it authenticates. Pramaan's connector model is close, but the broker's own entry points accept connections before anyone authenticates: in our reference deployment, the connector's entry point and the direct-connection entry point, each behind source-address connection limits that our host applies. The desktop client's UDP tunnel is also published, behind a token and an address check instead.
Questions
Do we have to switch off the VPN to start?
No. Shadow mode runs beside the proxy that signs people in today, which keeps deciding. An application reached only over the VPN, with no such proxy, cannot be shadow-tested.
Does shadow mode show who would gain access?
No. It counts only requests your current gate let through, so it shows who would be newly locked out, not who would be newly let in.
Does shadow mode cover direct connections?
No. Applications behind a connector and direct-connection applications have no shadow mode.
What happens to live connections when someone leaves?
Deactivating them revokes their sessions, their renewal tokens and every access token issued to them, and their live direct connections are cancelled, not merely refused next time.
Talk to us, or try it first
-
Book a walkthrough
Against your own apps, not slides.
-
Run the lab
It uses a demonstration account; none of your data is involved.
-
See pricing
Published floors, named-user bands and what every tier includes.