Skip to main content
Review and revision metadata
Review Date: 2026-06-16
Reviewer: Operations Manager

previous version on gdrive

myDRE User Management Policy

This policy establishes the governance framework for managing user access, identity lifecycles, and permissions within the myDRE ecosystem. It provides an audit-compliant blueprint mapped directly to ISO 27001:2023 (A.05.15, A.05.18, A.08.02), GDPR (Articles 5, 17, 24-1, and 25), and NIS 2 (Article 21-2(i) - Access Control & Asset Management).

This policy undergoes mandatory review and revision annually, or immediately following significant identity infrastructure modifications.

1. Scope & Identity Definitions​

This framework universally governs platform account lifecycles, directory properties, and identity states across all anDREa infrastructures.

Core Directory Fields​

  • "Other Email": A critical property inside the anDREa Microsoft Entra ID. myDRE uses this as the primary correspondence address and unique person identifier. It must be unique across the tenant (excluding test accounts and Research Support guests). Omitting a valid "Other Email" completely blocks Workspace access.
  • myDRE User Account: A primary platform identity entry inside Entra ID categorized as a "Member" and suffixed with @mydre.org. It is dedicated exclusively to logging into mydre.org and workspace Virtual Machines (VMs). It does not possess active mailbox capabilities.

User Account States​


┌──────────────────┐      Inactivity / Policy Breach      ┌──────────────────┐
│  Active Account  │ ───────────────────────────────────► │ Disabled Account │
└────────┬─────────┘                                      └──────────────────┘
         │
         │ Identity/MFA Modification or Missing Review
         ▼
┌──────────────────┐
│ Restricted State │ (Isolated at the individual Workspace layer)
└──────────────────┘
  • Active Account: Holds a verified "Other Email", fully configured password/MFA parameters, and an "Enabled" platform status in Azure.
  • Restricted State: Imposed strictly at the Workspace layer. The user can log into the platform but cannot access workspace resources. This is automatically triggered by "Other Email" modifications, overdue Access Reviews, or explicit assignment by an Accountable. Access can be restored following manual verification by an Accountable or Privileged Member.
  • Disabled Account: Imposed at the Platform layer. The user is completely blocked from accessing mydre.org due to prolonged inactivity, institutional offboarding, security compromises, or EULA violations.

2. Account Request, Provisioning, & Lifecycle Management​

To prevent unauthorized directory injection, manual write, modify, or delete privileges inside Entra ID are restricted exclusively to mandated anDREa personnel.

Manual Provisioning Pathways​

  1. Authorized Ingestion: Account generation requests must originate from Local Research Support (via the Admin Portal) or Workspace Accountables/Privileged Members (via the User Portal "Invite" feature).
  2. Data Constraints: Requests require a First Name, Last Name, and a valid, unique contact email mapped to the "Other Email" property.
  3. Automated De-duplication Check: The provisioning engine evaluates the incoming email (sanitized to lower-case, ignoring dots, and removing text between "+" and "@"). If the address exists, the creation process aborts and exposes the active username. If unique, the address is systematically reserved to prevent simultaneous duplication exploits.
  4. Activation Window: An activation hyperlink is transmitted to the user. If left un-activated, a reminder triggers on day 15. If still un-acted upon after 15 days, the request is purged, the identity deleted from Entra ID, and the reserved email released.

Automated SCIM Provisioning​

Tenants can deploy the System for Cross-domain Identity Management (SCIM) standard to link their corporate Entra ID instances directly to myDRE.

  • Automated Sync: SCIM automates identity generation when users enter scoped enterprise groups, alters platform configurations dynamically when corporate properties shift, and disables platform-level access the moment an identity is removed from an institutional group.
  • Technical Controls: Token configurations, secure mapping attributes, and operational procedures are governed under the SCIM Instructions.

Password and MFA Management​

  • Standard password parameters follow the strict guidelines of the Password Policy.
  • Users leverage self-service portals for standard password resets and MFA maintenance.
  • Local Research Support can log ticket-based password reset requests via the Admin Portal.
  • Ticket-based MFA resets are executed exclusively by anDREa Support. Resets are enforced immediately if an account is flagged as "Risky" or suspected of compromise by Microsoft Azure sentinel tools.

3. Workspace Interactivity & Auditing​

Adding and Removing Users​

  • Anti-Harvesting Control: Searching the directory via keyword or wildcard is strictly prohibited. Accountables or Privileged Members must explicitly copy and paste the precise @mydre.org username or verified "Other Email" to invite a researcher to a Workspace.
  • Accountable Transitions: To maintain workspace structural integrity, Workspace Accountables cannot self-remove from an active environment. Reassigning the role of Accountable must be performed by Local Research Support through the Admin Portal.
  • Administrative Override: anDREa Support can bulk-modify workspace roles via cryptographically logged backend scripts.

Access Control Activity Logging​

Every identity mutation inside a Workspace produces an ISO 8601 time-stamped log file tracking the initiator, target user, and specific action metrics.

Target AudienceLog Interface LocationMonitoring Scope
Accountables & Privileged MembersWorkspace Activity FeedTracks localized member additions, removals, and role updates.
Local Research SupportAdmin Portal DashboardTracks systemic tenant-wide activity, cross-workspace reviews, and restricted accounts.
anDREa Support TeamsInternal anDREa Management PortalMonitors cross-tenant operational compliance and systemic remediation events.

4. Retention, Deactivation, & Right to be Forgotten​

System Inactivity Clean-Up (Background Triggers)​

  • Never Signed-In: Accounts that remain un-activated 31 days after generation are hard-deleted, and their associated email handles are released.
  • Long-Term Inactivity: Accounts inactive for 1 year (366 days) are flipped to a Disabled platform state. Each automated disablement is digitally marked on the user entity for audit verification.
  • Hard Deletion Safety Buffer: If an identity remains disabled for an additional 2 consecutive years, a final notification is dispatched 15 days prior to a permanent hard delete.
important

To prevent identity fraud or invitation errors caused by username recycling, anDREa enforces a mandatory 2-year waiting period before a deleted username handle becomes available for reuse.

GDPR Article 17 (Right to be Forgotten) Implementation​

When a data subject submits an erasure request via support.mydre.org, the following protocol executes:

  1. The user must self-remove from all active Workspaces, permitting Accountables to execute localized study offboarding protocols.
  2. The user executes an irreversible erasure verification toggle.
  3. The Entra ID entity is structurally stripped of all personal identifiers (First Name, Last Name, and "Other Email" properties are completely dropped).
  4. System passwords and MFA secrets are wiped, and the anonymous placeholder account enters the automated inactivity queue for permanent cryptographic erasure.

Organizational Offboarding​

  • SCIM Environments: Removing the employee from the scoped organizational group triggers an automated platform block.
  • Manual Environments: Local Research Support submits a manual deactivation request via admin.mydre.org. If the researcher's corporate mailbox is already terminated, anDREa Support updates the "Other Email" property to an isolated placeholder. This instantly restricts the user across all Workspaces globally while preserving historical system logs.

5. Research Support Entitlements & Compliance Gating​

Local Research Support members function as tenant-level administrators, focusing on environment lifecycle orchestration rather than platform-level identity management.

Permitted Administrative Actions​

  • Submitting manual account provisioning or deactivation requests via admin.mydre.org.
  • Orchestrating, configuring, renaming, archiving, or decommissioning tenant Workspaces.
  • Reassigning Workspace Accountable roles and launching on-demand Access Reviews.
  • Extracting tenant-wide compliance metrics and activity logs.

Compliance Gating and Least-Privilege​

To satisfy NIS 2 and GDPR security requirements, administrative access to admin.mydre.org is strictly regulated:

  • Prerequisites: RS credentials are unlocked only after successful completion of mandatory training, passing the formal Research Support Quiz, and executing the corporate Support Agreement.
  • Enforced Revocation: If annual/biennial re-training requirements are missed, or if administrative roles remain completely unused over a prolonged observation period, anDREa will automatically revoke privileges and disable the administrative account to maintain a strict least-privilege state. All RS operations are continuously logged and audited for compliance.