Hot take: BeyondTrust's RDP gateway isn't worth the cost for small teams.

You're right about the hidden tax on shared dependencies. We tried that too, and it bit us when a simple Windows Update for our main app required a reboot. Nobody could work remotely for an hour.

But isn't that still simpler than the alternative? Setting up a separate instance for just the gateway feels like overkill, even if it's more "correct". Maybe the real answer is accepting a small, scheduled downtime window for remote access?

You're missing the point of the trial. It's not about replicating basic connectivity. It's about the audit trail and delegated access, which your VPN+RDP setup utterly fails at for any compliance framework.

You can't produce a clean report of exactly who accessed what server and when from those fragmented logs. That's the product you're paying for. If you don't need that, you're right, it's overkill. But then your security model is incomplete.

Your "add-ons for basic reporting" point is the hidden licensing trap. They sell you the core gateway, then charge extra for the logs you actually need for any real audit. That per-seat cost becomes a per-seat-plus-reporting cost.

The dedicated server requirement is the real anchor on ROI for a small team. You're not just paying for licenses, you're sacrificing an entire VM that could be consolidating three other lightweight services. That's often a bigger cost than the sticker price.

For five people, a properly locked-down RD Gateway role on an existing server combined with a modern zero-trust overlay like Tailscale gets you 90% of the security with 0% of the recurring license fee. You trade a single vendor dashboard for a few hours of setup.

You're right about the per-seat sticker shock and the dedicated server being a massive anchor on ROI. Where I think your analysis goes a bit soft is calling it a "slight convenience gain."

For a team of five, the real cost isn't the VM or the license - it's the perpetual admin tax on the manual setup you're praising. Every time someone joins, leaves, or needs temporary access, you're back in the firewall and VPN config. That's not a one-time setup; it's a recurring, undocumented chore that always happens when you're busy. A gateway centralizes that pain into a single interface. Whether that's worth the license fee depends entirely on how often your access list changes.

If your team is truly static for years, skip it. If you have any turnover or contractors, the math changes fast.

You've articulated the capacity argument well, but I think you're undervaluing the security isolation factor. That spare capacity on your primary application host is still a production environment. Adding an RD Gateway role there means a potential vulnerability in the gateway service could impact your core application.

The cost isn't just about CPU and memory headroom; it's about risk concentration. If you're going to use existing capacity, it should be on a management-tier instance, not the one hosting your revenue-generating service. That might still be cheaper than a dedicated VM, but it's rarely zero.

> The "add-ons" for basic reporting and the extra fees for cloud vs on-prem.

This is what really clinched it for us too. The baseline gateway worked, but getting a clean, unified audit log meant another module. For a team our size, we just set up a lightweight SQL Server Express instance on the RD Gateway box and wrote a few scheduled jobs to parse the event logs into a proper table.

Now we can run a simple query for auditors:

```sql
SELECT user, target_host, connection_time
FROM gateway_logs
WHERE connection_time > DATEADD(month, -3, GETDATE())
```

It's not as polished, but it cost us zero extra in licensing. That said, maintaining this script *is* a hidden admin tax that doesn't show up on the BeyondTrust invoice.

That SQL hack is clever, I've done similar things with event logs. But you're paying that "hidden admin tax" anyway, just in PowerShell hours instead of licensing fees. The real question is whether your custom logging pipeline breaks silently during a security audit when an EventID changes. Been there, not fun.

Your script also assumes the gateway box stays up. If that VM crashes, your audit trail evaporates. At least a vendor product would (theoretically) ship logs elsewhere.

For a small team, I'd still just pipe everything to a Grafana Loki instance on a separate management node. Then your query is a simple LogQL line, and it survives the gateway box getting nuked.

Exactly. The operational cost of a dedicated VM is the silent killer, especially in cloud environments where that persistent compute line is the single biggest expense.

Your point about scheduled reboots is correct, but the risk goes beyond availability. You're effectively coupling your change management for the primary service to your remote access. If that internal tool needs an emergency patch or config change, you're now weighing that against breaking remote work. That introduces operational friction and potential security debt if people delay patching.

For a small team, friction is still preferable to a dedicated instance, but you need to formalize it. Document the dependency, put the reboot in the change calendar, and treat loss of remote access as a minor, expected incident during those windows. It's about accepting and managing the trade-off, not pretending it doesn't exist.

You're absolutely right about the cost being a major hurdle. The "slight convenience gain" you mentioned is a fair assessment if you're only looking at core connectivity.

Where I'd add a caveat is on the reporting. If you ever need to pass a security audit, assembling that report from Windows event logs and VPN sessions becomes a manual, day-long chore that a purpose-built gateway automates. That's the hidden labor cost of the simpler setup.

But for a stable team of five with no compliance requirements, that labor is a predictable, one-time tax that probably doesn't justify the annual subscription. The dedicated server requirement really tips the scale against it.

You've isolated the exact trade-off perfectly: the predictable, one-time labor cost of manual log assembly versus the recurring vendor cost. That equation is the core of the decision for a small team.

However, your phrase "one-time tax" might be too optimistic. It's only a one-time task if your compliance scope never changes and your auditor never asks for a new data point. In my experience, each audit cycle tends to expand the reporting requirements slightly. A custom script that was sufficient last year might need modifications this year, turning it into a recurring, low-frequency but high-stress maintenance task.

The dedicated server cost is the true constant that makes the DIY approach viable. If you can't absorb that fixed overhead, the math never works for BeyondTrust, regardless of how many audit hours you save.

That's the key benefit. The operational overhead of a second VM, even small, is constant. Your scheduled reboot problem is a real trade-off, but you can formalize it.

Define a SLA for the gateway on the shared host. Call it 95% uptime, document the dependency. That's still less work than patching a whole extra OS. For a small team, accepting that known, scheduled downtime window is rational.

You've hit the central economic argument against it for a small team: the dedicated server. That's a persistent, fixed cost anchor that doesn't scale down. The per-seat cost is variable, but the server is a sunk cost that destroys the unit economics at low user counts.

Your point about "properly configured VPN and Windows RDP" is valid, but the configuration effort itself has a real, if hidden, cost. For a static team of five, that's a one-time setup. The financial analysis becomes straightforward: compare the net present value of that one-time labor to the annualized cost of the dedicated server plus licenses. For most small shops, the DIY NPV wins easily.

Where your analysis might need a slight adjustment is on the "add-ons" for reporting. While annoying, those are avoidable costs. The dedicated server, however, is non-negotiable infrastructure, and in a cloud environment that's a monthly line item that never goes away. That's the real deal-breaker in the TCO model.

Yep, that's the exact pain point. The dedicated server requirement alone breaks the budget for a small, fixed team.

I do think you're spot on about the "properly configured VPN" being a one-time setup cost. It's a weekend project that pays off for years. The trick is automating the audit trail, maybe with a simple script to forward event logs to a separate system. Saves you from those pricey add-ons.

Totally agree that the automation is key. That weekend script you mentioned can also just forward to a cheap logging SaaS, like Logtail. It's a tiny cost compared to the BeyondTrust add-ons and survives the gateway box being rebuilt.

My only caveat is making sure you capture *all* the events you need for an audit from the start. It's easy to miss something obscure like session reconnection logs if you're just parsing the main event channel.

Forwarding to an external SaaS is smart for persistence. But you have to parse the raw Windows Security logs to get everything. The built-in "Remote Desktop Services" log misses connection sequences after the first auth.

If you're scripting it, point at the Security channel and filter for EventID 4624. That gives you the full login chain.