I am trying to define the boundary between two broad types of users. The first are those who make use of corporate systems (accounting, ERP, CRM, etc.) and this also includes B2B users, for example external consultants, market partners, businesses which use our corporate services, and so on. The second type are end-users which use customer-facing applications, like mobile apps etc.

In my mind it feels intuitively clear, but I am having difficulty articulating this distinction. I am trying to find, firstly, correct vocabulary for referring to these two types of users, and secondly, a simple set of rules for determining the boundary between these two.

The reason for this is because it will impact the technical implementation of user authentication and authorisation. One idea I had was to differentiate based on the type of data the users would use. The first uses corporate data, whilst the second uses personal and private data. For the first group of users (the only type we have had to deal with thus far) they are all managed within Active Directory and authentication/authorization is implemented via a Single Sign On service. However, this is not necessarily appropriate for mobile app users (for example), but I need to give clear definitions and input to our security team who will need to amend security policies and directives which govern how we manage user identities, authentication and authorization.

I would appreciate some direction, particularly if there is some well-established best practice or industry standard which relates to my question.

  • If authentication is your primary driver for the user types, I would start with three of them: Human (an account tied to a specific person), Corporate (an account shared by multiple persons in a business/department) and Machine (an account for use by automated systems). Then see where it makes sense to allow each type of user. Oct 5, 2018 at 7:00
  • Can you give an example what you mean by "differences in the technical implementation of user authentication and authorisation"?
    – Doc Brown
    Oct 5, 2018 at 8:31
  • @BartvanIngenSchenau This is not useful, as my question is directly about the two types of Human accounts. Machine-to-Machine authentication is handled in a completely different way, as is corporate entities.
    – ralfe
    Oct 5, 2018 at 8:39
  • 1
    Hm, not sure if you are overthinking this. What makes users which are managed in an Active Directory different from those who are not, is, that they are managed in an Active Directory system. Same holds for "mobile users". So why not simply make exactly this kind of authorization/authentification the distinctive criteria?
    – Doc Brown
    Oct 5, 2018 at 11:52
  • 1
    Users are People, not access permissions. Users play roles and those roles authorize activity. If you classify users with types or kinds, sooner or later you'll have problems when one user plays multiple roles.
    – Erik Eidt
    Oct 5, 2018 at 16:08

1 Answer 1


The problem:

An authentication and access policy based such a broad and fuzzy categorisation of users seems a very bad idea:

  • First, corporate system also contains private data, not only about the user himself but about other users and third parties.
  • Second users may use several kind of applications, for example customer facing applications and CRM. Even if a given user is using only one of them, it can evolve over time.


First, make a difference between user account (identification of a user) and users (persons).

You can then define purpose oriented categories of user accounts, without having to worry about the persons that may correspond to several categories. Typically, you would consider categories such as staff (first ring of trust), external service providers, and customers (or general public, if you provide large audience internet services).

Some principles that you could enforce:

  • Compartmentalisation: any user account should belong only to one category. This is especially important if you're working with sensitive information systems: if a same user account would belong to groups of different trust level, there would be a risk to get the credentials highjacked on a lower security system and see more secure systems compromised.
  • Authentication policy could depend on the account category: for example "key device for staff and service providers and user id+password for external customers".
  • General access control checks could catch inconsistencies, with the help of some simple rules on categories (e.g. "category X of application can only be accessed by accounts of category A", or "Air-gapped systems shall be used only be user accounts local to the isolated network", or "Staff using our public products shall use the staff account for internal applications, and a different general public account when using our products as end-user".

Now such large categories are not granular enough for being sufficient as sole subject of access rules. So on each system (or for each category of accounts), you'd also need a role model that defines what a user of a given role is entitle to do or not to do.

  • Thank you, that is quite helpful. Would you group B2B and B2B2C with "external service providers"?
    – ralfe
    Oct 6, 2018 at 7:52
  • I was thinking about external staff working on your systems. It's not clear if your B2B are external systems from some provider, or if it's systems controlled by your organisation (and with a similar level of security than other corporate systems?), with external users.
    – Christophe
    Oct 6, 2018 at 8:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.