One gateway for every privileged protocol you run
Wardengate Access Gateway replaces scattered bastions and shared jump boxes with a single control plane. Brokered SSH, RDP, and database sessions; identity-bound policy; just-in-time elevation with approvals—wired to the IdP you already run.
Approve, time-bound, and revoke access to every target from one gateway—no per-host exceptions or parallel jump tiers.
Every brokered session is tied to a named person or workload identity from your IdP. No shared accounts, no orphan keys.
Consolidate jump hosts, break-glass boxes, and standing VPN paths into one audited choke point operators actually prefer.
Inside the gateway: one brokered path, four enforcement layers
Operators and workloads meet a single gateway. Inside it, policy, brokering, recording, and secrets each run as distinct subsystems—so one session passes through every control without a detour.
Identity
Operator
IdP identity
Service
Workload identity
Gateway control plane
Single pathWardengate core
Targets
SSH · Linux
RDP · Windows
Database
Operators and workload identities arriving from your IdP.
Policy engine, protocol broker, recorder, and vault in a single plane.
SSH, RDP, and database endpoints reachable only through the broker.
What it does
Centralized access control, without the operational drag
The gateway is the one place access is granted, enforced, and reviewed. Operators get a clean connection experience; security gets deterministic policy and an evidence trail for every session.
Terminate SSH, RDP, and database protocols at the gateway. Forward only what policy allows, apply inline inspection, and hand operators a native client experience—no custom agents on targets.
Map roles and groups to the specific hosts, clusters, schemas, and commands they need. Entitlements are computed per session, not baked into long-lived accounts on the underlying systems.
End a session, rotate a secret, or pull an entitlement and the effect is immediate. Because credentials are brokered in line, there is no lingering key material to chase across fleets.
SAML, OIDC, SCIM, and directory sources feed Wardengate. Targets stay on their existing OS, DB engine, or cloud control plane—the gateway adapts to the estate, not the other way around.
Security operators can watch live sessions, join for pair review, or terminate with a click. Suspicious commands trigger step-up prompts or an immediate disconnect before damage propagates.
A horizontal control plane that scales to tens of thousands of targets, yet stands up in an afternoon for a team of ten. Pricing and footprint track your actual privileged surface.
Policy engine
Policies that follow the identity, not the network
Access decisions read the person, the target, the time of day, the device posture, and the sensitivity of the action—then return allow, deny, or step-up. The same rule works the same way whether the operator is on the corporate LAN, a cafe, or a vendor laptop.
Rules are code: versioned, reviewed, and testable. Dry-run a policy change against historical session metadata before you ship it.
Inputs the engine reads
- IdP group, role, and attribute claims
- Target tags: environment, data class, owner
- Device posture signals from the endpoint
- Time, geography, and request context
Decisions the engine makes
- Allow, deny, or require step-up MFA
- Route to an approver before connect
- Gate specific commands or SQL patterns
- Record, redact, or flag the resulting session
Just-in-time access
Elevation with an expiration date, not standing privilege
Most privileged work is bursty. Wardengate treats it that way: an operator requests the target and window they need, an approver signs off, and the entitlement evaporates on schedule. Nothing to forget to revoke.
Request
Operator picks a target, role, and window from the catalog. Reasons are captured as structured fields, not free-form notes.
Approve
Policy routes to the right approver—manager, on-call, or the asset owner—via Slack, Teams, or the console. Auto-approve for low-risk paths that have been pre-blessed.
Expire
The entitlement is bound to a TTL. When the window closes, the session ends and any brokered credentials are rotated. No manual cleanup.
Secrets brokering
Users authenticate as themselves. Targets never see them.
Wardengate injects credentials into brokered sessions at connect time. Operators never copy a key, never paste a password, never hold long-lived material that has to be rotated when someone changes teams.
Bring your own vault or use Wardengate's built-in store. Either way, the gateway is the only process that ever touches the target credential, and every retrieval is logged against the requesting identity.
What brokering eliminates
- Shared SSH keys sitting on laptops and in pipelines
- Break-glass admin passwords in a wiki or password manager
- Database superuser credentials emailed to vendors
- Rotating every secret after every personnel change
- Guessing which keys are still in use and which are orphaned
Protocol coverage
Broker the protocols operators actually use
Native clients on one side, governed policy on the other. No custom shells, no forced-fit portals.
Replace the bastion fleet
The jump-host era was a workaround. Wardengate is the fix.
What bastions leave you with
- One host per environment, each with its own account drift
- SSH keys as de facto policy, stored on operator laptops
- Audit that ends at a shared login, not a real person
- No practical way to record or review what happened on target
What the gateway gives back
- One policy surface, rendered against every target type
- Identity-bound sessions with brokered, ephemeral credentials
- Session records tied to the named human who ran them
- A shrinking, measurable privileged surface over time
Ready when you are
See what a single, audited path to production looks like
We will walk you through a brokered SSH, RDP, and database session on your stack—plus the policy, JIT, and recording model behind them.