Short answer: Siebel user licensing offers three metrics. Named User Plus counts every internal individual authorized to access Siebel, active or not. Registered User counts every external party provisioned with a login. Concurrent User counts only peak simultaneous sessions. On top of the metric, each person is assigned to a higher-priced Employee class or a lower-priced Customer/Partner class — and misclassification is one of the most expensive Siebel audit findings.
Key Takeaways
- Named User Plus counts every authorized individual in the Siebel user repository regardless of last login. Separated employees left active typically represent 15-20% of the count and are the single largest Siebel audit finding.
- Registered User counts every external portal account, active or dormant; high-volume customer portals accumulate large registered counts that surface unexpectedly in an audit.
- Concurrent User counts peak simultaneous sessions only. Where peak concurrency is a small fraction of total population, it can cut licensing cost substantially despite a higher unit price.
- Employee-class licenses cost the most per user; Customer/Partner-class licenses cost less. Across Siebel engagements, the initial Oracle audit claim is typically 3-5x what the customer actually owes once classes and inactive accounts are corrected (Oracle Licensing Experts, 2026).
- Oracle's LMS scripts read the S_CONTACT table and treat every active record as a licensed user — making repository hygiene the highest-impact lever you control before any renewal or audit.
What This Guide Covers
What are the Siebel user licensing metrics?
Short answer: Siebel is licensed on three user metrics — Named User Plus, Registered User, and Concurrent User — plus legacy Application User terms on older contracts. The metric defines who counts and when, and you cannot mix freely: each module's order form specifies a metric you must license against.
Siebel user licensing rests on a simple but consequential idea: Oracle prices Siebel by who is authorized to use it, and the definition of "authorized" varies by metric. A Named User Plus is an individual authorized to use the program, whether or not they are actively using it. A Registered User is an external party provisioned with a Siebel login. A Concurrent User is one of the peak simultaneous sessions running against the application. Legacy agreements may also carry grandfathered Application User terms with their own definitions.
The metric is fixed per module on your Siebel order form — you do not get to retroactively choose the cheapest one at audit time. That makes the original purchasing decision, and any renewal re-papering, critical. Choosing the wrong metric for your usage profile can lock in years of overpayment. This page sits within our broader Oracle Siebel Licensing Guide, which maps the full module, support, and migration picture; here we go deep on the user metrics alone.
How does Siebel Named User Plus count licenses?
Short answer: Named User Plus counts every individual authorized to access Siebel, regardless of how often they log in. An employee who used Siebel once last year counts. A separated employee whose account stays active counts. Each developer with a personal admin login counts separately. Oracle reads the user repository, and an active record equals a licensed user.
Named User Plus is the default Siebel metric for internal Employee deployments, and it is unforgiving. Oracle's position is that the licence entitlement runs from the date of the system record, not from active usage — so the question is never "did this person use Siebel," it is "does this person have an active record." That single rule is the root of most Siebel audit exposure.
Three recurring findings drive the bulk of Named User Plus back-licence claims. First, former employees whose Siebel accounts were never deactivated: they hold active records, so Oracle counts them, and enterprises commonly find 15-20% of their Named User count consists of separated staff. Second, individual developer and admin accounts: twenty developers each with a personal Siebel admin login need twenty Named User licences, not a single shared developer right. Third, integration accounts with human-identifiable logins (john.smith@company.com rather than SIEBEL_INT_001), which Oracle may attempt to classify as Named Users rather than exempt system accounts.
Insider note: Oracle's LMS scripts do not measure activity — they measure existence. Every active row in the Siebel S_CONTACT table is a potential licence. The defensive work is therefore repository hygiene, not usage analysis: if the record is gone before the script runs, it cannot be counted.
What is a Siebel Registered User?
Short answer: A Siebel Registered User is any external party provisioned with a Siebel login — typically customer or partner self-service portal users — counted whether or not they ever sign in. The per-user price is low, but high-volume portals can accumulate enormous dormant registered counts that become audit exposure.
Registered User is the metric Oracle applies to customer- and partner-facing Siebel deployments, where the population is external and usage is assumed to be light. Because the unit price is low, enterprises often under-manage these accounts — and a self-service portal that has provisioned logins for hundreds of thousands of customers over a decade can carry a registered count far beyond anything the original contract anticipated.
The trap is that dormant registered accounts still count. A customer who registered once five years ago and never returned remains a Registered User in Oracle's reckoning. Where a portal has grown organically, the registered population can quietly exceed the licensed quantity, and Oracle's audit will surface the gap as a back-licence claim plus 22% support backdated to first overage. Disciplined de-provisioning of inactive portal accounts — and a contractual definition that ties Registered User to active accounts where you can negotiate it — is the buyer-side defence.
Our License Optimization service reads your order forms, maps deployed users to the correct metric and class, and right-sizes the count before Oracle measures it.
When does Concurrent User licensing save money?
Short answer: Concurrent User counts only peak simultaneous sessions, so it wins where total population dwarfs simultaneous use. If your peak concurrency multiplied by the concurrent-to-named price ratio is less than your total authorized population, Concurrent User is cheaper — common in large, occasional-use service or field deployments.
Concurrent User licensing measures the high-water mark of simultaneous sessions, not headcount. It suits estates with a large authorized population but low simultaneity — for example, ten thousand occasional service users where only six hundred are ever logged in at peak. The concurrent unit price runs several times the Named User price, but where simultaneity is a small fraction of population, the math favours Concurrent User decisively.
The break-even is a straightforward calculation worth running before every renewal: estimate your true peak concurrency, multiply by the concurrent-to-named price multiplier in your contract, and compare to your total authorized population. If the concurrent figure is lower, Concurrent User wins. The risk to manage is the opposite of Named User: with Concurrent User you must not exceed your licensed peak, so capacity headroom and session-management controls matter. We model both scenarios in any engagement so the metric choice is evidence-based rather than assumed.
| Metric | What it counts | Best fit | Primary audit risk |
|---|---|---|---|
| Named User Plus | Every authorized internal individual, active or not | Employee CRM, stable populations | Separated employees and shared admin logins left active |
| Registered User | Every external party provisioned with a login | Customer and partner self-service portals | Dormant portal accounts accumulating past the licensed quantity |
| Concurrent User | Peak simultaneous sessions | Large population, low simultaneity | Exceeding licensed peak concurrency |
| Application User (legacy) | Authorized users under grandfathered contracts | Older agreements with favorable terms | Definition drift across contract amendments |
Employee vs Customer/Partner user classes
Short answer: On top of the metric, every Siebel user is assigned to a class. Employee-class licenses cover internal staff at the highest per-user price; Customer/Partner-class licenses cover external users at a lower price. Misclassifying external users as Employee-class overstates cost, while serving Employee functionality to external users without the right licence creates understatement risk.
The user class is a second pricing dimension that sits alongside the metric, and it materially changes per-user cost. Siebel Employee licences cover internal users running Siebel for internal CRM processes — sales teams, service agents, field technicians — and carry the highest per-user price because Oracle assumes heavy, strategic usage. Siebel Customer/Partner licences cover external users accessing self-service portals or partner-facing functionality, priced lower on the assumption of lighter, narrower usage.
Misclassification cuts both ways and both ways cost you. Classifying external partner-portal users as Employee-class inflates your licence count and liability — you pay the premium price for users who should sit in the cheaper class. Conversely, deploying full Employee-class functionality to customers without proper Customer-class licensing creates understatement risk that Oracle will back-assess. Oracle's LMS audit distinguishes between internal and external authentication domains, so the class assignment must match the actual access pattern. Aligning every user to the correct class is one of the most reliable cost corrections we make in a Siebel review.
How does Oracle audit Siebel user counts?
Short answer: Oracle's LMS scripts query the Siebel user repository — chiefly the S_CONTACT table and the associated security access groups — and report every active record as a licensed user. The audit treats existence, not usage, as the trigger, so the initial claim routinely overstates true liability by 3-5x before entitlements and inactive accounts are corrected.
Oracle provides LMS (License Management Services) scripts built specifically for Siebel. They query the user repository for active records and produce a report in which every account with active status is a licensed user, regardless of last login. Oracle's stance is consistent and well-rehearsed: an active record equals a licensed user, and the entitlement runs from the date of the system record.
Because the script measures existence rather than activity, the raw audit output almost always overstates true liability. Across Siebel engagements, the initial Oracle audit claim is typically 3-5x what the customer actually owes once you remove separated employees, deduplicate accounts, reclassify users into the correct class, and apply your actual entitlements (Oracle Licensing Experts, 2026). The work of audit defence is forensic and evidence-based: you do not argue the script is wrong, you demonstrate which records should never have counted. For the full audit playbook — what the scripts measure, what you are obliged to share, and how to challenge findings — see our Oracle Audit Defense Guide and our Audit Defense service.
How to right-size your Siebel user count
Short answer: Deactivate separated employees, remove test and duplicate accounts, pool individual admin logins into shared service accounts, reclassify external users out of Employee-class, and document the evidence. Repository hygiene before an audit or renewal routinely removes 15-20% of the licensed base — the single highest-impact, fully buyer-controlled lever.
Right-sizing is the lever you fully control, and it works because Oracle counts records, not people. The sequence is practical: run a full extract of the Siebel user repository; deactivate every separated employee and contractor; identify and remove duplicate and test accounts; convert integration logins to non-human service-account naming; pool individual developer admin access into shared service accounts where your security model allows; and reclassify any external users wrongly sitting in Employee-class licences. Each step is documented with evidence so the reduced count is defensible.
Do this before renewal and before any audit, not in response to one. A documented reduction from, say, 5,000 to 4,000 Named Users drops your support base by 20% directly, and the same discipline strengthens your position if Oracle does initiate an audit. This pre-emptive cleanup is the core of our License Optimization service, and it pairs with the wider cost-reduction levers — third-party support, module rationalisation, and support caps — covered in the Siebel Licensing Guide. For results, see how we eliminated audit exposure in our healthcare compliance case study.
Siebel User Licensing FAQ
What is the difference between Siebel Named User and Concurrent User?
A Siebel Named User Plus is every individual authorized to access Siebel, counted whether or not they log in. A Concurrent User counts only the peak number of simultaneous sessions. Named User suits stable internal populations; Concurrent User suits large populations with low simultaneity and can cut cost where peak concurrency is a small fraction of headcount.
What is a Siebel Registered User?
A Siebel Registered User is any external party provisioned with a Siebel login, typically for customer or partner self-service portals, counted whether or not they ever sign in. The per-user price is low, but high-volume portals can accumulate large dormant registered counts that surface as audit exposure.
Does Siebel count inactive or separated employees as licensed users?
Yes. Oracle's LMS scripts read the Siebel user repository and treat every active record as a licensed Named User, regardless of last login. Separated employees whose accounts were never deactivated are counted, and they typically represent 15-20% of a Siebel Named User count — the single largest source of overstated licensing.
What is the difference between Siebel Employee and Customer/Partner user classes?
Employee-class licenses cover internal Siebel users — sales reps, service agents, field technicians — at the highest per-user price. Customer/Partner-class licenses cover external self-service and partner-portal users at a lower price. Misclassifying external users as Employee-class overstates cost; deploying Employee functionality to external users without proper licensing creates understatement risk.
How do I reduce my Siebel user license count before an Oracle audit?
Deactivate separated employees in the Siebel repository, remove test and duplicate accounts, pool individual developer admin logins into shared service accounts, reclassify external users out of Employee-class licenses, and document the evidence-based count. Removing the 15-20% of dead accounts alone typically cuts a fifth off the licensed base before any renewal negotiation.
Can I change my Siebel licensing metric to a cheaper one?
The metric is fixed per module on your order form, so you cannot retroactively switch at audit time. You can, however, re-paper the metric at renewal or new purchase. Model your true peak concurrency against your authorized population first, then negotiate the metric that fits your usage profile into the contract before signing.
Is your Siebel user count overstated?
We extract your Siebel repository, strip out the dead accounts, align every user to the correct metric and class, and hand you a defensible count — before Oracle's LMS scripts run. Independent, buyer-side, 600+ engagements.