---
title: "Identity & access"
description: "How we run identities: Entra ID or on-prem AD (also hybrid), MFA for everyone, phishing-resistant for admins, Conditional Access as standard, separate admin accounts, access reviews, offboarding on the last day."
canonical: "https://corevatis-redesign.pages.dev/en/technology/identity-access/"
lang: en
schema_type: WebPage
hreflang:
  de: "https://corevatis-redesign.pages.dev/de/technik/"
  en: "https://corevatis-redesign.pages.dev/en/technology/"
---
# Identity & access

Almost every attack starts with a sign-in. That is why security for us starts not at the firewall but at the account: who is this, from which device, and are they allowed to do this right now?

## In brief

- We run what you have: Entra ID, on-prem Active Directory or both (hybrid)
- MFA for all accounts; admins phishing-resistant (FIDO2/passkey)
- Conditional Access as a standard set: MFA, legacy auth blocked, device state, countries
- Separate admin accounts — nobody works day-to-day as domain or global admin
- Access review at an agreed cadence; offboarding on the last day

## What we do

Directory (Entra ID, Active Directory, hybrid with Entra Connect), sign-in (MFA, password policy per BSI/NIST, single sign-on), access rules (Conditional Access by location, device state, risk), rights (role-based groups, least privilege, time-limited admin rights), lifecycle (joiner, mover, leaver) and detection of account takeovers (see identity protection). Our own service portal has its own sign-in (SSO service, open source) — on request connected to your Entra ID, so your IT needs no second set of credentials.

## How exactly

| Parameter | Procedure |
|---|---|
| MFA | Mandatory for all accounts, no exceptions for executives. Admins with FIDO2 key or passkey; SMS only as a transition. |
| Conditional Access | Standard set: MFA everywhere, legacy authentication blocked, access only from compliant or registered devices, country restriction, risk-based re-verification (with Entra ID P1/P2). Deviations documented. |
| Admin accounts | Separate from the everyday account, named, with MFA. Rights time-limited (PIM with Entra, documented elevation with AD). Two emergency (break-glass) accounts, stored offline and monitored. |
| Groups and rights | Role-based instead of per person; approvals via groups, no individual rights. Vendor access time-limited. |
| Passwords | Long instead of complex, no forced rotation without cause (BSI/NIST), checked against known leaked passwords. |
| Review | Regularly: admins, guests, orphaned accounts, group memberships, application consents. Cadence agreed per client — quarterly is our proposal. |
| Leaver | On the last day: block account, revoke sessions, remove MFA devices, forward or archive mailbox per rule, device returned and wiped. Checklist in the service portal. |

## What you receive: Access review

A document you can sign off: who has which rights, which accounts are orphaned, which guests and vendors still have access — and what we cleaned up as a result.

- Admin accounts and roles
- Accounts without sign-in for X days
- Guests and external shares
- Groups with access to sensitive data
- Applications with tenant consent
- Conditional Access policies and exceptions

## Tools

- **Entra ID / Active Directory** — Your directory — we run it, it is yours. Data location: your tenant / your server. Replaceable by: —.
- **Entra Connect** — Hybrid: on-prem AD synchronised with Entra ID. Data location: your server. Replaceable by: —.
- **Intune** — Device compliance as a condition for access. Data location: your tenant. Replaceable by: Group Policy (limited).
- **Cloudflare Zero Trust** — Access to internal applications without VPN — identity- and device-based. Data location: EU regions configurable. Replaceable by: another ZTNA solution.
- **SSO-Dienst des Serviceportals** — Sign-in to our service portal; connected to your Entra ID. Data location: operated by us, Germany. Replaceable by: open source.
- **Microsoft Defender for Identity / Entra ID Protection** — Detection of account takeovers with the right licence, complemented by Wazuh rules on sign-in logs. Data location: your tenant / operated by us, EU. Replaceable by: Wazuh alone.

## What we deliberately do not do

- No shared admin accounts, no "admin password list"
- No MFA exception "for the boss" — attackers know who the boss is
- No 30-day password rotation as security theatre
- No permanent global admin for us: our rights are named, time-limited and logged

## Prerequisites on your side

- Access to the tenant or domain with documented handover
- MFA-capable devices or keys for all users
- Inventory of applications that sign in against the directory
- A process at the client that reports joiners and leavers to us

## Questions from IT

**We only have an on-prem Active Directory, no cloud. Does that work?**
Yes. The standard applies there too: separate admin accounts, MFA at the entry point (e.g. Zero Trust access instead of VPN), groups instead of individual rights, reviews, offboarding checklist. What is harder in on-prem AD — Conditional Access, risk detection — we tell you openly, and whether a hybrid connection would make sense.

**How do you handle other vendors' access?**
Time-limited, named, with MFA, in its own group — and visible in the review. Open-ended vendor accounts are one of the most common entry points we find during takeovers.

**How quickly is an account closed when someone leaves?**
On the last day if we know it: account blocked, sessions revoked, MFA removed. For immediate terminations within service hours right after your notice. The process is in the checklist so nothing is forgotten — not even the mailbox forwarding.

**Do we need Entra ID P1 or P2?**
For Conditional Access, yes: P1 (included in Microsoft 365 Business Premium). P2 adds risk-based policies and time-limited admin rights (PIM) — sensible from a certain size or with elevated protection needs. We tell you which licence you really need, not which one we could sell.