Choosing which modules to turn on, and in what order
Four modules and a posture assessment. What each one demands of you — a consent, an agent rollout, an inventory — and the order that gets value soonest.
Qorionix is four capabilities that are normally four separate products, plus an assessment that ties them together. This article is about the sequencing decision: which to switch on, in what order, and what each one is actually going to ask of you before it produces anything.
The recommendation, in one line: posture assessment, then identity, then logs, then endpoints, then privileged access last. The rest of the article is why, and what each step costs you in your own time rather than in money. An overview of all four with their published limits is at the platform page.
The five things, and what each demands of you
The column that matters is the third one. Every module is technically easy to enable and they differ enormously in what they need from a human before they start returning anything.
| Capability | What it gives you | What it needs from you |
|---|---|---|
| Microsoft 365 posture assessment | 82 deterministic checks producing a report that names your real administrators, applications, devices and risky sign-ins. | One consent. An app registration in your own tenant, twelve read permissions and an admin consent — about fifteen minutes. Nothing is installed and nothing in your tenant changes. |
| Identity and access | Adaptive multi-factor, passkeys, network zones, and an ordered policy engine with a trace naming which rule decided a sign-in and why. | Decisions, not deployment. Which zones, which rules, who enrols a second factor. Nothing to install on a machine. |
| Log collection and detection | Your logs in one place, normalised to one schema, matched against a detection library mapped to MITRE ATT&CK with false-positive guidance on every rule. | Connecting your sources, plus a fortnight of patience. Microsoft 365 and Entra ID arrive with the connection you have already made; Windows Event Log, syslog, CloudTrail and Google Workspace each need configuring. |
| Endpoint detection and response | A sensor reconstructing what a suspicious process actually did, and reversible response actions with an undo handle recorded before the action is taken. | An agent rollout. A signed installer onto every machine you want covered, and a way to push updates. This is the only module with a genuine deployment project attached to it. |
| Privileged access | Administrator credentials held in a vault and injected into a recorded session, so the person doing the work never sees the password. Rotation on a schedule. | A credential inventory. A written list of every privileged account, what it is for and who uses it. Most organisations our size do not have one, and producing it is the actual work. |
The order, and the reason for each position
Posture assessment first, because it costs one consent
It is read-only, it changes nothing, it disrupts nobody, and it is the only thing on this list that tells you something about your own business before you have configured anything. Every subsequent decision is better informed for having read it — including which of the other four modules you actually need. Start here even if you have already decided to buy everything. See Connect Microsoft 365.
Identity second, because that is where the incidents start
Almost every intrusion into a company your size begins with a working password. Identity is not the boring pillar; it is the one that decides whether the other three ever get exercised. It also asks the least of you — the work is deciding policy rather than deploying anything, and the flagship automated action, asking for a second factor when a sign-in looks wrong, is self-correcting when it is wrong because the user proving their identity is the remediation.
Logs third, because detection needs data and data needs time
Connect the sources early even if you do not intend to look at the queue for a month, because the behavioural detections need five to fourteen days of your real traffic before their output is worth acting on. Starting the clock is free. Judging the output before the clock has run is the mistake. Retention is set by your tier — 14 days on Free, 90 on Core and Protect, 365 on Complete, 730 on Enterprise — so this is also the point at which the retention figure on your licence starts to matter.
Endpoints fourth, because it is a deployment project
The sensor ships as a signed MSI for Windows, deb and rpm packages for Linux and a package for macOS. It is not exotic, but it is software on every machine, and if you cannot roll software out to your machines then the endpoint half of the product cannot help you — that is a property of the situation, not something we can engineer around. Do the identity work first; it is cheaper, less disruptive, and covers where the incidents actually begin.
Privileged access last, because of the inventory
This is the module that needs something you probably do not have: a list of every privileged credential in your estate, what it is for, and who holds it. Discovery scanners help you build it, but the judgement — is this service account still needed, who signs off on rotating it — is yours and cannot be delegated to software. Doing this module last means doing it with a posture report in front of you, which is a great deal easier than doing it cold.
What each plan includes
Modules are entitlements on your licence record rather than switches in a settings page. The posture assessment is not one of the four licensed modules — it is available from the entry tier upward and is not gated.
| Tier | Modules on the licence | Retention | Seat ceiling |
|---|---|---|---|
| Free | Identity and access only | 14 days | 10 |
| Core | Identity and access, log collection and detection, endpoint detection and response | 90 days | None |
| Protect | Everything in Core, plus infrastructure log sources, threat hunting and custom detections | 90 days | None |
| Complete | All four, adding privileged access and Compliance Autopilot | 365 days | None |
| Enterprise | All four, in a dedicated cell in a home region you declare | 730 days | None |
A request to a module your licence does not include is refused rather than returned empty. You get an HTTP 402 carrying tier_upgrade_required and the name of the feature, which is a deliberate choice: an empty list is indistinguishable from a clean estate, and a security product must never let a commercial boundary look like an all-clear.
Limits worth knowing before you commit
Each module has published limits. These are the ones most likely to affect a decision you are about to make, and they are stated here rather than discovered later.
- Identity — inbound provisioning is not in production
- Creating users and memberships automatically from your HR or directory system over SCIM is built and works, but the canonical mount still points at a shadow store pending a one-line change. Treat it as beta and do not plan a joiner-leaver process around it yet. Deprovisioning or deleting a user is never automated at any tier, by design. See identity and access.
- Logs — two ATT&CK tactics are not covered, permanently
- Reconnaissance and Resource Development are absent from the coverage map and will stay absent. Both happen outside your estate — an attacker researching your staff on a professional network, or registering a lookalike domain — and generate no telemetry inside your tenant or on your machines. Claiming coverage would be a fabrication. See logs and detection.
- Endpoints — the sensor update channel verifies before it applies
- The sensor updates itself from a signed channel: it verifies a signed manifest and the artefact hash, and refuses an update it cannot verify. macOS is excluded until the macOS package is notarised, so Mac hosts still need whatever mechanism you already use to push software — factor that into the rollout decision. See endpoints and response.
- Privileged access — no pixel replay for Windows sessions
- The native RDP gateway is beta and produces a parsed, searchable event transcript rather than a video recording. That is genuinely better for finding the moment a command was typed and genuinely worse if you expected to watch a session back. We would rather say so now than let you find out during an investigation. See privileged access.
- Privileged access — two rotation targets are mock-tested only
- Six rotation engines are verified against real systems. Entra service-principal and Palo Alto rotation have been tested against mocks only, with no live tenant or appliance confirming them, so treat those two as unproven until we say otherwise.
If you only turn on one thing
Turn on the posture assessment. It is one consent, it produces a document naming real people at your company, and for most organisations our size the findings in it represent more available risk reduction than anything else on the list. Only about a third of EU enterprises have any document setting out their security measures at all, so the artefact is worth having quite apart from what it says.
The honest counterpoint: a posture report is a snapshot of configuration, not a watch on activity. It will tell you an administrator has no second factor. It will not tell you that somebody signed in as them from Lagos at three in the morning. That is what the logs and endpoint modules are for, and it is why the recommendation is an order rather than a single answer.
What to do next
- Connect Microsoft 365 — step one regardless of which modules you end up on.
- Read what the platform does and does not do — the published limits, in the same unflattering detail as the capabilities.
- Work through the first-week checklist — the task-level version of this article's ordering argument.
- Compare the tiers — remembering that the figures there are indicative until the provisional notice comes off.