Getting started with Kaseya MDR as a standalone user

This article helps you get started with Kaseya MDR when it is purchased and accessed as a standalone product. It explains what to expect after purchase, how access is established, and how to orient yourself safely in the platform after your first login.

Use this article if:

  • You purchased Kaseya MDR on its own.

  • You received a Kaseya MDR onboarding or activation communications.

  • You do not access Kaseya MDR from RocketCyber or as part of a Kaseya 365 subscription.

If you are an existing RocketCyber customer, see Getting started with Kaseya MDR as a RocketCyber user.

If Kaseya MDR is included in a Kaseya 365 subscription, see Kaseya 365 Endpoint Pro: Getting started with Kaseya MDR.

What this guide is for

This guide helps you:

  • Access Kaseya MDR for the first time

  • Understand how authentication and multi‑factor enforcement work

  • Complete required security readiness steps

  • Confirm that the core areas of the platform are available

  • Validate that Kaseya MDR is ready for use

This guide does not cover day‑to‑day alert investigation, response playbooks, or advanced detection tuning. Those topics are covered in the linked articles and in Using Kaseya MDR.

Permissions

To complete the steps in this article, you must have administrative access to the Kaseya MDR environment associated with your organization.

What to expect after purchase

After purchasing Kaseya MDR as a standalone product, onboarding typically involves a small set of related emails sent to the implementation or primary contact on the account. These messages support different parts of the onboarding process and may arrive close together.

Examples include:

  • Contract or order confirmation emails

  • Billing or invoice notifications

  • A Kaseya MDR welcome or activation email

  • In‑product guidance (WalkMe)

  • Optional onboarding assistance or services

These communications relate to different parts of the onboarding and provisioning process and may be received independently.

Accessing Kaseya MDR for the first time

Account activation and first login

One of the onboarding emails provides the information needed to activate your Kaseya MDR account and sign in for the first time. This message typically includes a link that starts the account‑setup process, such as verifying your details or setting a password.

When you are ready to begin:

  • Open the Kaseya MDR email that contains activation or access instructions.

  • Follow the steps provided to complete account setup.

  • Sign in with the credentials you just created.

At this stage, your goal is simply to confirm that:

  • You can sign in successfully

  • You can reach the Kaseya MDR interface consistently

NOTE  If you are unsure which email contains access instructions, or if you did not receive an activation message, contact your Kaseya account representative or Support for assistance.

Identity validation and safe access establishment

When Kaseya MDR is purchased as a standalone product, the system does not assume whether you already have an existing RocketCyber or SaaS Alerts account.

To prevent unintended cross‑tenant access, identity and organization association are intentionally validated during first access. In some cases, you may be prompted to confirm whether an existing account should be linked or whether a new tenant should be used.

This validation exists to ensure accounts are connected correctly and that customer data is not exposed to the wrong organization.

Authentication and security readiness

After signing in for the first time, you may be prompted to complete required security steps.

Depending on how your environment is configured, authentication may be handled through one of the following models:

Direct sign‑in to Kaseya MDR

  • Users sign in at https://manage.kaseyamdr.com using Kaseya MDR credentials.

  • Two‑factor authentication (2FA) is enforced by Kaseya MDR.

  • Users manage 2FA from Settings > Account.

  • Directly within Kaseya MDR

Unified Login with KaseyaOne

  • Users authenticate through KaseyaOne.

  • MFA is enforced during the KaseyaOne sign‑in flow.

  • Kaseya MDR relies on KaseyaOne for identity verification.

The authentication model determines where security controls such as multi‑factor authentication (MFA/2FA) are enforced.

At this stage, confirm:

  • That you can sign in successfully

  • Where authentication is managed in your environment

For more information, see Unified Login with KaseyaOne.

Complete required security readiness

Before investigating alerts or enabling response actions, security requirements must be satisfied.

Depending on how authentication is configured, this may include:

  • Enabling multi‑factor authentication (2FA) for your user account

  • Confirming that MFA enforcement is handled through Unified Login

If prompted to complete security steps during sign‑in, complete those steps before continuing.

Security readiness is a prerequisite for certain response and automation capabilities.

If your organization uses direct sign‑in to Kaseya MDR, enabling 2FA is strongly recommended and required for some response and automation capabilities.

  1. Sign in to Kaseya MDR.

  2. Go to Settings > Account.

  3. Enable Two‑Factor Authentication.

  4. Set up your authenticator app.

If your organization uses Unified Login, MFA is enforced through KaseyaOne and does not need to be enabled separately in Kaseya MDR.

Post‑access onboarding: establish baseline, configure intentionally

After you have access to Kaseya MDR as a standalone customer, onboarding focuses on establishing a clear baseline and deciding what to configure next, rather than verifying inherited state.

In a standalone environment:

  • Organizations, users, agents, and integrations are not assumed to exist

  • What appears after first login represents a starting point, not a prior configuration

  • Many features are available immediately, even if they are not yet in use

The sections below help you:

  • Confirm that access and scope are correct

  • Understand default behavior and available control surfaces

  • Decide which areas to configure now versus later

This guide does not walk through every option. Detailed configuration is covered in the linked articles.

Why this matters

Before creating organizations, connecting tools, or enabling response actions, confirm that your user account is correctly associated with the intended Kaseya MDR environment.

  1. Access Kaseya MDR directly using its URL: (https://manage.kaseyamdr.com).

  2. Sign in with your credentials.

  3. Verify that you can authenticate consistently and access the platform.

For information on authentication and security controls, see Unified login with Kaseya MDR and Securing your account with two‑factor authentication (2FA).

Why this matters

In a standalone environment, organizations are not created implicitly based on external systems. Administrators must explicitly confirm whether organizations already exist or need to be created.

  1. Navigate to Organizations.

  2. Review whether any organizations are present.

  3. Confirm that organization names and scope reflect your intended structure.

If no organizations exist, this is expected in a net‑new environment. Organizations can be created as needed before connecting data sources or assigning users.

For details, see Managing organizations.

Why this matters

Telemetry, alerts, and investigations depend on connected data sources. In a standalone environment, integrations are not connected automatically.

  1. Go to Organizations > Edit Organization > Applications.

  2. Review whether any applications or data sources are connected.

If no integrations are present, no action is required immediately. Integrations can be added incrementally based on your environment and monitoring goals.

Connect only the tools that apply to your environment. After connecting a tool, allow time for telemetry ingestion before expecting alerts or activity.

For details, see Connecting data sources and integrations.

Why this matters

Kaseya MDR uses an explicit role‑ and scope‑based access model. In a standalone environment, administrators define who can access the platform and what actions they can perform.

In Settings > Users:

  1. Review existing users.

  2. Confirm which users are assigned the Admin role.

  3. Confirm which users have limited permissions based on role.

In Settings > User Privileges, review which feature sets (such as Respond or Unify) users are allowed to manage.

If managing multiple organizations, review Group Access to control which organizations users can see or manage.

This step ensures permission alignment and governance. It does not affect detection logic or monitoring behavior.

For details, see User roles and permission boundaries.

Why this matters

In a standalone Kaseya MDR environment, agents are not present by default and are introduced only after deployment or integration. Monitoring coverage depends on which agents or data sources are connected after onboarding.

If no agents appear under Devices > Agents, this is expected until deployment or integration occurs.

Agent deployment and configuration are covered in:

Agent behavior and visibility depend on the products and licenses applied to each organization.

Why this matters

SOC settings define how monitoring, escalation, and SOC interaction operate within Kaseya MDR. These settings are available immediately, even in net‑new environments.

  1. Go to Settings > SOC Settings.

  2. Review available options and defaults.

  3. Confirm how monitoring and escalation are expected to work in your environment.

This is a required first‑time review to understand behavior, not a required tuning exercise unless you choose to change defaults.

For details, see Configuring SOC Settings.

These settings shape the day‑one experience by controlling alert delivery, severity behavior, and suppression.

Alert delivery (PSA and Email)

Why this matters

Defines how alerts are communicated externally and helps prevent unnecessary notification noise.

In Settings > PSA & Email:

  1. Review email and PSA delivery configuration.

  2. Designate primary delivery channels where appropriate.

For details, see Notifications, PSA, and external communications.

Why this matters

Controls how repeated or low‑value alerts are suppressed over time.

In Settings > Customize Alert Severity:

  1. Review default severity behavior.

  2. Decide whether to enable Quiet Mode based on alert volume expectations.

See Managing alert severity and detection tuning and Quiet Mode overview.

Why this matters

Power Filters allow expected or trusted activity (such as known IP ranges or ASNs) to be excluded from alerting. Power Filters affect visibility, not telemetry collection or SOC‑managed detection logic.

In Settings > Power Filters:

  1. Review scope options (global, organization, account).

  2. Define filters only for known, trusted activity.

For details, see Power Filters and allowlisting logic.

Why this matters

Analysis is the primary workspace for viewing alerts, events, and historical activity once telemetry is available.

After integrations are connected, it may take time for data to appear. A lack of immediate alerts does not indicate a problem.

Use Analysis to:

  • Confirm telemetry is flowing.

  • Understand how alerts and events appear in your environment.

  • Distinguish expected behavior from noise.

Open Analysis, review filters, and explore a small sample of data as it becomes available.

No configuration changes are required as part of this step.

See Investigating alerts using the Analysis page.

Why this matters

Response and automation features can affect systems and users.

During initial onboarding:

  • Use alert‑only workflows where possible.

  • Observe behavior before enabling automated actions.

  • Confirm internal approval and authorization boundaries.

There is no requirement to enable automated response actions during initial onboarding.

For details, see Using the Respond module and Respond actions.

Proceed to normal operations

Once access is confirmed, security readiness is complete, and telemetry is validated, you can begin using Kaseya MDR for investigations and response based on your organization’s readiness.

At this point:

  • Use Kaseya MDR as the primary interface for alerts and investigations.

  • Expand integrations and response capabilities intentionally over time.

Related articles

  • Unified Login with KaseyaOne: Explains how Unified Login affects authentication, MFA enforcement, and sign‑in behavior when accessing Kaseya MDR through KaseyaOne

  • Securing your account with two‑factor authentication (2FA): Shows how to enable and manage 2FA for Kaseya MDR and explains how authentication requirements affect response and automation capabilities

  • Managing organizations: Explains how organizations are created, scoped, and managed in Kaseya MDR once access is established in a standalone environment

  • Connecting data sources and integrations: Describes how to connect endpoints, SaaS applications, and other data sources so telemetry can begin flowing into Kaseya MDR

  • How Kaseya MDR works: Introduces the core mental models behind alerts, investigations, and response so you understand how the platform behaves before day‑to‑day use

  • Using Kaseya MDR: Provides guidance for reviewing alerts, investigating activity, managing signal and noise, and using response capabilities once onboarding is complete.