Remote access licenses: how to count users across branches

The problem: users exist, but it’s unclear how to count them

In branch networks, overspending on remote access licenses often appears unnoticed. One office adds a couple of staff, another brings in a consultant for a week, a third opens a temporary shift. Individually these look minor, but together they turn into recurring “buy as you go” purchases.

Confusion starts with a simple question: are you counting people, accounts, devices, or concurrent connections? When branches answer differently, RDP user accounting quickly turns into a spreadsheet of guesses. One-off exceptions (a contractor, a vacation replacement, an intern) become the norm over time.

Under-licensing risks more than fines and audit claims. It affects operations: access suddenly blocks needed people, admins manually reassign rights, and the business loses time. Overbuying is also harmful: money goes to idle licenses instead of real modernization (servers, network, support).

Usually fall through the cracks are those not on the payroll: external consultants and contractors, interns, seasonal workers, temporary crews, and replacements. There are also “hidden” users: managers who connect rarely, accounting during reporting periods, or employees who work from home a couple of days a month.

Before calculating licenses, clarify four things: who will connect (employees and all temporary roles) and from which branches; what matters more — “each person always has access” or “the number of simultaneous sessions”; which systems require remote access (1C, document management, CAD, terminal apps); and how often the user composition changes (seasonality and project peaks). If these answers are not fixed, licensing becomes reactive: first they connect, then remember that access must be “legalized.” That’s how chronic overspend appears.

Basic terms so everyone speaks the same language

When people discuss remote access licenses, they often argue about meanings rather than numbers. Some count people, others count accounts, and some count devices. The result is buying “with a buffer” and paying extra for years.

Three concepts not to confuse:

• User — a specific person (employee, consultant, intern).
• Account — a login in the domain, an app, or a gateway.
• Device — a PC, laptop, thin client or home computer used to connect.

Licensing is usually tied to one of these “anchors.” So two people taking turns on one terminal and one person using both a laptop and a home PC will result in different counts depending on the model.

Named and concurrent models sound complex, but the logic is simple. Named: the license is assigned to a person (or sometimes to an account), and hours don’t matter. Concurrent: what matters is the maximum number of simultaneous connections during a peak.

The type of remote access also affects counting. VPN provides a network tunnel but doesn’t always mean terminal (RDP) access. RDP/terminal sessions are often counted by sessions and terminal logon rights. VDI is closer to assigning a dedicated virtual workplace and usually requires separate licensing logic.

One more common distortion: “local” vs “remote” staff is not about job title but about scenario. If an accountant connects remotely once a month, it’s more useful to rely on actual logins than on the mere existence of an account.

What data to collect before calculating licenses

Counting remote access licenses blindly almost always costs more. You need data not about “how many employees the company has” but about who actually connects, when and to what.

Start with a simple map: branches, departments and roles. It’s important to know not only “where they connect from” but “why”: accounting, cash desk, engineers, call center, doctors, teachers, contractors. Different roles have different login frequency and different access criticality.

Record work schedules and peaks. The same team can require different numbers of licenses depending on shifts and seasonality. If branches operate at different times, licenses are often reused. If peaks coincide, you’ll need more buffer.

Next, analyze accounts. A common cause of overspend is shared logins like “operator1” or “cash,” which several people actually use. For licensing and security these are different stories, but for calculation you must honestly separate: how many unique people use remote access, how many accounts exist (including test and spare accounts), whether shared accounts exist and who is responsible, who connects rarely (1–2 times a month) and who connects daily.

Make a separate list of systems requiring access. Often licenses are bought “for terminals,” and later it turns out many users only need mail, a web portal or 1C, not a full remote desktop.

The last block is connection statistics from logs, without diving into technical details. Request exports showing concurrent connections during peak hours, session durations, login frequency by user, and entry points (for example, a terminal server or individual applications). Even 2–4 weeks of data usually give a real picture.

A simple guide: a branch has 30 employees but the peak concurrent terminal-server connections are 12 because some work in shifts and others don’t use remote access at all. That concurrent peak often defines the minimum procurement baseline.

How to pick a licensing model for branches

The chosen model determines whether you’ll be constantly buying extra remote-access licenses or comfortably handling seasonal peaks. For branches two things usually matter: similar roles across cities and varying time loads (morning, month-end, reporting days).

Named, concurrent and device-based: what to choose

Named (per-user) suits when the staff composition is stable and each person needs regular access. Control is simpler: one person, one account, one license, even if they connect from office, home, or while traveling.

Concurrent licenses often look cheaper when not everyone connects at once. The risk is that real peaks in branches can happen simultaneously: shift changes, cash operations, month-end accounting. If seats run out, work stops and you’ll have to buy licenses urgently.

Device-based counting makes sense when access is required from specific workstations rather than by individuals — for example, in a classroom, reception desk or security post where different shifts use the same PC.

Practical rule:

• Named — stable employees with frequent access from various locations.
• Concurrent — many infrequent users whose peaks don’t coincide.
• Device-based — fixed access points and shift work on the same PC.

Accounting for peaks and reserve to avoid overpaying

Look at the maximum on problem days, not the average. Reserve is needed for predictable events: vacation and sick-leave replacements, business trips, on-call work, and seasonal projects.

A practical approach: allocate a small reserve for critical roles (those who would stop a process) and check whether others can cover peaks via shifts or task sequencing.

Step-by-step: how to calculate the number of licenses needed

To avoid overpaying, count the real need for simultaneous work, not everyone who theoretically has access.

Five steps to a working number

1. Split users into groups: staff, contractors and consultants, temporary personnel. Note who connects from branches and who connects externally.

2. For each group describe scenarios: daily work, rare logins (1–2 times a week), access only during specific periods (month-end, inventory, project launches).

3. Calculate the peak concurrent connections. Use the busiest hour or two (often morning, after lunch, or reporting days). If there is no data, start with manager surveys and a short 1–2 week measurement.

4. Add a controlled buffer. Typically 10–20% to the peak, but more important than a percentage is the reason: planned new branch, upcoming audits, seasonal crews. Record the buffer and review it.

5. Fix rules for issuing and revoking access: who requests, who approves, and how quickly access is removed after work ends. Without this the calculations soon go stale.

Example: a network of 4 branches. Payroll has 120 people but peak simultaneous sessions are 28 (accounting and sales). Contractors connect per project, maximum 4 concurrently. Temporary staff during quarter-end add 6 more. Peak is 38. Add a 15% buffer for planned growth — you get 44 licenses.

To keep numbers stable, assign roles: IT tracks connection usage and disables access; department heads confirm true need; security/compliance sets access durations and monitors contractors; purchasing revises license counts on a schedule (for example, quarterly).

External consultants and contractors: how to account without chaos

A contractor needs access for a specific task and time. Treating contractors as staff inflates license counts and leaves forgotten active accounts across the infrastructure.

A simple, effective practice is separate accounts per contractor with predefined time limits. It’s easier to see who connected and when.

Organizing contractor access without overspending

First decide if contractors connect continually or episodically. For rare access (1–2 times a month) it’s often cheaper to grant access on request and limit it by time than to keep a permanently enabled user.

A few rules that bring order:

• Separate contractor accounts with expiration dates.
• Access only to required resources (by groups and roles).
• Enable by request and disable after task completion (just-in-time).
• Restrict connection windows if work is limited to business hours.
• Use MFA when possible.

Preventing access from lingering after task completion

The most common source of chaos is a finished project but the account remains active. A simple process helps: a request, owner approval, automatic expiration, and a closure check.

For internal checks keep: the contract or amendment, the access request, approvals, work dates, connection logs and a completion certificate. This is crucial in branch networks where contractors may work across multiple sites.

Temporary staff and seasonal load spikes

Temporary staff arrive in waves: inventory, admission campaigns, reporting periods, project teams. The problem isn’t headcount but issuing access “just in case” and forgetting to revoke it. Then licenses start “leaking” into past projects.

The most practical preparation for peaks is to separate forecast from fact. Forecast with branch managers: how many people, how many shifts, which systems, and whether full remote desktops are needed daily or only for task completion. Record the fact via issued accesses and real logins to be more accurate next season.

Rule for temporary access

Control seasonality and part-time work with a short rule filled in before granting access and checked on renewal: start and end dates, role and rights limits (e.g., only 1C/CRM/mail), approving manager, login type (personal account or shared pool), and the basis (contract, request, project number).

Choose licensing by scenario: if staff rotates frequently but few work concurrently (for example, 8–10 of 30 temporary workers per shift), a shared pool of concurrent licenses is often cheaper. If a person is assigned for the whole season, accesses regularly and needs personal rights and an audit trail, named licenses are better.

To maintain control during constant rotation, require a rhythm: a weekly list of active temporary accesses by branch with manager confirmation. For example, hire 12 operators for 3 weeks — grant access for 21 days and renew only for those who remain.

Example scenario: counting licenses for a multi-branch network

Situation: 6 branches, 120 employees. Additionally — 15 contractors (auditors, implementers, lawyers) and up to 20 seasonal workers at peak. Remote access is not needed by everyone, but by those connecting to desktops or apps from branches, home or travel.

Split roles: cash desks and operators, accounting, HR, IT, management. For calculation focus on concurrent connections rather than headcount.

Assume remote access is used by: cash and operators (40 people, 2 shifts), accounting (18), HR (6), IT (8, on-call and fieldwork), management (12, irregularly).

Estimate peak concurrent sessions by shifts. Example logic:

• Day peak: 22 (cash) + 16 (accounting) + 4 (HR) + 5 (IT) + 6 (management) = 53 concurrent.
• Evening peak: 18 (second cash shift) + 4 (IT) + 3 (management) = 25 concurrent.

Do not add all contractors at once. If realistically only 5 consultants work simultaneously, count 5 not 15. Count seasonal workers by concurrent usage: e.g., seasonal adds up to 10 daytime connections.

If one branch peaks in the morning and another in the evening, a shared pool (central server/farm) helps: take the global peak rather than sum all branches. If infrastructure is isolated by branch, count peaks per branch separately and demand will be higher.

Result for procurement: calculated maximum (e.g., 53 + 10 seasonal + 5 contractors = 68) plus a small buffer of 5–10% for unexpected shift overlaps and urgent connections.

Typical mistakes that create constant overspend

Overspend rarely stems from one big mistake. It’s usually a set of small habits that go unreviewed for years.

The most common confusion source is shared accounts. With logins like “cash,” “warehouse” or “shift-1” it’s impossible to tell how many people actually used access and who performed actions. This breaks calculations and complicates security and incident investigation.

Second mistake — counting “by heads” without considering concurrency. A branch may have 40 employees but only 8–10 remote users in peak hours. Ignoring schedules and shifts leads to inflated purchases.

Third — contractors and consultants. They get access “for a few days,” the project ends, but the account and rights remain. After six months such “temporary” users number in the dozens and surface in audits.

Five common failures that sustain overspend:

• shared accounts for departments or shifts instead of personal logins;
• buying by staff numbers without checking concurrent sessions;
• granting contractors access without expiration and a business owner;
• no regular disabling of inactive accounts and rights reviews;
• mixing different remote access methods (RDP, VPN and others) without unified accounting.

A simple scenario: quarter-end temporary team granted quick access and never disabled after work. The pattern repeats, and a year later it looks like “more users,” while actually the tail of forgotten accesses grew.

Short checklist before buying or reviewing licenses

Spend 20 minutes before purchasing or renewing remote-access licenses to go through items that often save money and headaches.

1) Users and responsibilities

List all user categories and who is responsible: branch staff, central office, external consultants, contractors, temporary personnel. Each category needs a process owner (e.g., HR for temporaries, procurement or security for contractors, IT for staff). Otherwise RDP user accounting becomes message-thread chaos.

2) Concurrent connections and peaks

Make sure you know peak concurrent sessions by branch, not only total headcount. Licenses are usually consumed by morning shifts, month-end accounting and days when many connect simultaneously.

Minimum check: you have concurrent session data by branch for the last 1–3 months, peak days (month-end, season, project) are noted, and you know which groups work in non-overlapping shifts.

3) Temporary accesses without manual control

For temporaries and externals set issuance rules in advance: who creates access, the term, and who approves renewals. The must-have is an expiration date that disables access automatically.

4) Regular review

Schedule a quarterly license audit: who left, who joined, which branches changed schedules, which projects finished. Annual reviews usually lead to overspend because temporaries have time to accumulate.

5) Plan for growth and seasonality

Keep a simple forecast: new branches, system launches, seasonal loads, contractor use. If the infrastructure is local (PCs, workstations, servers), tie license planning to upgrade and support cycles to avoid mismatches.

Next steps: lock the process and tidy infrastructure

To stop buying remote access licenses “just in case,” you need a process, not a one-off calculation. Start small: inventory, rules, pilot in one branch.

Practical start: what to do in 2–3 weeks

Pick one branch as a pilot and run the full cycle:

• Gather facts: user list, roles (staff, contractor, temporary), schedules, real concurrency.
• Agree rules: who gets remote access, how it’s issued, for how long, who approves.
• Set up tracking: a single registry of requests and grants so you don’t hunt “who opened what.”
• Fix limits: allowable buffer and thresholds that trigger recalculation.
• Compare results: calculated need vs actual, where deviations occurred and why.

Present the pilot as a one-page summary for leadership: e.g., “Branch A: 120 staff, 18 remote roles, peak concurrency 11, 20% buffer for vacations and replacements, total 14.” Specify that a user is a person (not a device) and how contractors are counted.

When to rethink remote access architecture

If you constantly hit terminal server limits, users complain about speed, and peaks are regular, evaluate options: better terminal setup, VDI for specific groups, or using VPN where appropriate. Architecture should match real scenarios, not last year’s habits.

Connect security and HR processes so access is revoked on time. Require expiry for any contractor or temporary employee; renewals only by new requests. Dismissal or contract end should trigger checks and deactivation.

For a turnkey project you can engage a system integrator. GSE.kz (gse.kz) helps design remote access infrastructure, provides 24/7 support and selects equipment for your load model, including S200 servers and in-house workstations.