Who actually needs a Qorionix account

The most useful sentence in this article is the first one: most of the people in your organisation do not need a Qorionix account. Not as a cost-saving measure, and not as a restriction — they simply have no use for one, and giving them one makes your estate slightly worse rather than slightly better.

This surprises people, so it is worth explaining properly before getting to the list of who does need one. The mechanics of the invite flow itself — the button, the one-time invitation link, and the three steps the invited person works through — are in Create your organisation and invite your team and What an invited user actually receives. This article is about the decision rather than the procedure.

Two populations that get confused

There are two entirely separate groups of people in play, and conflating them is what produces a user list with forty names on it in a firm where four people will ever open the console.

Identities the platform watches

Everyone with a Microsoft 365 account at your company. Qorionix reads your directory through an application registration in your own tenant, using a grant type with no signed-in user behind it. Your staff appear in the posture report by name, in alerts as subjects, and in the risk engine as entities — and not one of them ever signs in to Qorionix, is prompted by Qorionix, or knows it exists. This is the population the product is actually for.

Users of the Qorionix console

The much smaller set of people who log in here to read a report, approve a change, work an alert or export evidence. These are the accounts you create. Each one is a credential that can be phished, a session that can be stolen and a name in your audit trail, so each one should have a reason.

Because the connection to Microsoft 365 authenticates as an application rather than as a person, none of this depends on who set it up. If the administrator who created the connection leaves and their account is disabled, the connection keeps working — and equally, our access does not quietly widen when somebody is promoted. Watching an identity and holding an account are unrelated facts.

Who genuinely needs an account

Three jobs require a login. If a person does none of the three, they do not need one, however senior they are.

In a firm of fourteen that is typically three or four accounts, and two of them belong to the same two partners. In a firm of two hundred it is rarely more than eight. The number that should worry you is not a small one.

One addition to the three: a second administrator. Not because the work needs two, but because one administrator is a single point of failure with a holiday schedule. Give it to a person rather than to a shared mailbox, and give it to somebody who will still be at the company next year.

Which role, and why the default should be the smallest

There are three built-in roles, created with your organisation. The full breakdown, including what is deliberately withheld from a member, is in Who can see and do what. The short form:

• admin — full organisation access. Everything, including credential retrieval, billing, detection-rule authoring, the audit log and who else has access. The role is granted every permission in the catalogue automatically, including ones added in future releases.
• member — the person who works the queue. Triages alerts, works incidents, contains a machine, runs searches, uploads compliance evidence, raises a privileged-access request. Cannot change who has access, cannot retrieve a credential, cannot alter a detection rule.
• viewer — read-only. Never a read that would expose a secret, a monetary figure or a security-administration surface. Right for an auditor, a board member and a new hire's first fortnight.

The reasoning behind that is worth stating plainly rather than as a slogan. A role decides how much damage one compromised account can do. Every extra administrator is another account that, if stolen, hands over your entire organisation — the credential vault, the billing relationship, the detection rules and the audit log that would otherwise record the theft. Three administrators is three times the target, not three times the resilience.

If the three roles genuinely do not fit — a bookkeeper who should see compliance evidence and nothing else, a contractor who needs the privileged-access side without the identity side — create a role rather than stretching member. The permission catalogue has 85 named permissions and the picker is grouped by module, so a narrow role is a five-minute job.

The external IT contractor

Most organisations our size have one, and they usually need admin to do the work you are paying them for. Two things make that acceptable rather than reckless.

1. Put a review date in the calendar the day you grant it. Quarterly is enough. The question is not whether they are trustworthy; it is whether the engagement that justified the access still exists.
2. Never make them the founding administrator. Whoever creates the organisation is the account that cannot be locked out by a colleague's mistake, and that should be a partner or the owner. You can give a contractor the admin role five minutes later; you cannot easily undo having handed them the founding account.

The seat ceiling, and the message you will see

Your licence carries a maximum number of accounts, and unlike most of the published allowances this one is genuinely enforced by the server. Adding a member past the ceiling is refused with an HTTP 402 and this body:

{"error":"feature_not_available","feature":"max_users",
 "required_tier":"professional"}

The count is of memberships in your organisation — console accounts — not of identities in your Microsoft 365 directory. That distinction matters because the published price is quoted per identity while the enforced ceiling counts logins, and the two numbers are not the same thing. Pricing is provisional and not yet contractual in any case; if the arithmetic matters to your budget, ask us for a written quote rather than deriving one from the pricing page.

Two things to do before you press send

1. 1

   Tell your staff on your usual internal channel first

   An unexpected email asking somebody to create an account on a security platform is indistinguishable from a phishing attempt, and the better trained your people are, the more likely they are to delete it — which is the correct instinct and you should not train it out of them. Two lines in your normal channel, sent before the invitations, is the whole fix.

2. 2

   Choose each person's role in their own invitation — there is no batch

   The Invite dialog takes exactly one email address, one first name, one last name and one role, for one person. There is no multi-address field, no paste-a-column box and no batch behaviour of any kind, so two admins and nine viewers is eleven separate dialogs. Get the role right in each one; repairing eleven memberships afterwards takes longer than picking eleven roles now. If eleven is too many dialogs, use the CSV import instead — see Inviting people one at a time, or in bulk.

Keeping the list honest

A user list is only as good as the last time somebody looked at it. Twice a year, open the Users page and ask one question of every row: what does this person do here that requires a login? Where the answer is a shrug, disable the account rather than deleting it — the account stops working immediately and their history stays attached to a real name.

When somebody leaves, suspending the account now does most of the work for you: it ends every session that account holds and deactivates every API key issued under it in this organisation, immediately. What it does not touch is a key the same person holds under a different organisation they also belong to, so check for that, and do the equivalent in Microsoft 365. The full leaver procedure is at the end of Who can see and do what, and Suspending, offboarding and deleting a user has the detail.

What to do next

1. Read the role breakdown before you assign anything — particularly the one thing a member can do that surprises people.
2. Follow the invite procedure — the wizard, and what an invited person actually has to do once their link arrives.
3. Have each of them set up two-factor authentication — two minutes each, and an administrator without a second factor is a critical finding in your own first report.