CyberArk Secrets Rotation Service (SRS): Complete Guide

Secrets Rotation Service (SRS) is CyberArk’s next‑generation rotation engine delivered as a SaaS backend for Privilege Cloud, designed to replace the legacy Central Policy Manager (CPM) for secrets management. It provides cloud‑native scalability, central policy control, and connector‑based access to targets via the Connector Management agent, eliminating the need to deploy and maintain dedicated CPM Windows servers. For CyberArk architects, SRS shifts rotation design from on‑prem Windows services and local plugins to a service‑plus‑connector model with centralized platform policies, modern APIs, and enhanced visibility.

Core concepts and terminology

• Secrets Rotation Service (SRS) – CyberArk’s SaaS rotation engine that manages rotation, verification, and reconciliation of privileged secrets for Privilege Cloud platforms and accounts.

• Connector Management agent – Lightweight agent installed on customer “connector” hosts, which executes SRS rotation plugins against on‑prem or cloud targets.

• Connector pool – Logical grouping of connectors that provides high availability and load balancing for modern services like SRS and Discovery.

• Secrets rotation policy – Per‑platform policy defining rotation/verification/reconciliation behavior (intervals, retries, linked logon/reconcile accounts, behavior overrides) that SRS enforces.

• Rotation plugins – Platform‑specific executables and configuration files cached on connector machines and invoked by SRS via the Management Agent to perform change/verify/reconcile actions on targets.

• SRSExecutionUser – Local technical account created on connector machines to execute rotation actions with minimal required privileges.

Architectural overview

High‑level architecture

At a high level, SRS is an active‑active SaaS service in the CyberArk Privilege Cloud backend that orchestrates rotation flows, while all target‑side activity is executed through connector machines running the Connector Management agent.

Key architectural elements:

• SaaS rotation engine in CyberArk’s backend:

  • Stores and evaluates secrets rotation policies.

  • Schedules and triggers rotation/verification/reconciliation operations for managed accounts.

  • Interacts with the Digital Vault/Privilege Cloud backend for account metadata and credential updates.

• Connector Management agent on customer connector servers:

  • Maintains a secure outbound connection to the CyberArk SaaS backend (Connector Management service).

  • Receives plugin payloads and job instructions for SRS rotations.

  • Executes cached rotation plugins locally against targets and reports results back.

• Digital Vault / Privilege Cloud data layer:

  • Stores account objects, secret versions, Safe memberships, and audit data.

  • SRS updates credential versions there after successful rotations.

Data and control flow

A typical password rotation flow with SRS is:

1. Scheduling and selection

   • The SRS backend evaluates master policy and platform‑level secrets rotation policies to determine which accounts are due for rotation or verification.

2. Job creation

   • For each due account, SRS creates a rotation job and assigns it to a connector pool that can reach the account’s target network.

3. Connector dispatch

   • The Connector Management service sends a job description and plugin identifier to a specific connector in the pool, considering availability and health.

4. Plugin execution

   • On the connector, the Management Agent:

     • Ensures the appropriate rotation plugin version is available in its local cache (rotation_[platform]_[version]).

     • Runs the plugin under the constrained SRSExecutionUser context (or a related internal execution user) with the account metadata and required secure parameters.

     • Connects to the target system (for example, AD, Windows local, Linux, database, SaaS API) and performs change/verify/reconcile per plugin logic.

5. Result reporting and Vault update

   • Plugin exit codes and logs are returned to SRS, which updates job status and writes the new secret value/version into the Vault on success or records a failure with error reason.

6. UI and API visibility

   • Administrators see real‑time rotation status, last/next rotation, failure reasons, and can trigger manual operations via the Privilege Cloud UI or REST APIs.

Differences from CPM architecture

• Location of rotation engine:

  • CPM: Windows service installed on customer‑managed servers, communicating directly to the Vault over port 1858 and to targets.

  • SRS: SaaS rotation engine; no dedicated rotation Windows server is deployed, only connector machines with the Management Agent.

• Connectivity pattern:

  • CPM: Initiates direct connections from CPM servers to targets.

  • SRS: Uses existing Connector Management channels; connectors maintain outbound connectivity to the CyberArk SaaS service and then to targets, simplifying firewall rules and centralizing connectivity.

• Scaling and HA:

  • CPM: Scaling often means adding more CPM servers and distributing platforms; HA is manual (multiple CPMs, safe‑based or platform‑based segmentation).

  • SRS: Active‑active SaaS backend plus connector pools; scaling is largely automatic on the service side and horizontal on the connector side.

SRS components in detail

Secrets Rotation service backend

The SRS backend in Privilege Cloud:

• Maintains master rotation policy defaults and per‑platform secrets rotation policies (including rotation/verification/reconciliation options, retry intervals, linked accounts, and behavior overrides).

• Manages associations between accounts and platforms, including dependent accounts (for example, linked logon and reconcile accounts).

• Orchestrates job queues, manages retries, and handles error categorization (transient vs permanent failures).

• Exposes APIs for:

  • Master policy configuration and retrieval.

  • Account‑level rotation/verification operations.

  • Advanced operations like enabling/disabling automatic Visual C++ redistributable deployment on connectors.

Connector Management agent and connector pools

The Connector Management agent is the execution environment for SRS and other modern services such as Discovery and SIA. Key properties:

• Installed on Windows connector servers via an installation wizard or automation, typically into C:\Program Files\CyberArk\Management Agent by default.

• Registered into one or more connector pools, which are then associated with target networks or logical domains for SRS policies.

• Caches SRS plugins in C:\Program Files\CyberArk\Management Agent\Cache\rotation_[platform]_[version] folders, one per platform and version.

• Uses specific local accounts for operations:

  • CyberarkManagementAgent – service account used by the agent.

  • SRSExecutionUser – minimally privileged user created automatically for SRS rotations, with controlled filesystem and logon rights.

Rotation plugins

SRS rotation plugins:

• Are shared across platforms that use the same rotation logic; they encapsulate how to connect to and modify secrets for a specific target (for example, Windows local, Linux, web application, database).

• Include:

  • Executables (EXE/DLL or similar) implementing protocol and change logic.

  • Optional prompts files, process files, and configuration files for interaction flows.

• Are deployed from the backend to the connector cache on first rotation for each platform and re‑deployed on failure or version updates.

• Can be customized for edge cases such as localized prompts in terminal/web plugins by editing cached plugin files on the connector, with the caveat that such changes must be re‑applied or coordinated with CyberArk Support to persist across plugin updates.

For web application secrets rotation, additional plugin prerequisites include browser drivers and .NET dependencies as described in the web application plugin documentation, with drivers placed under C:\Program Files\Cyberark\BrowserDrivers and referenced via WebDriverUpdater configuration.

SRSExecutionUser and hardening

On each connector machine, the Management Agent creates an SRSExecutionUser when the first secrets rotation occurs. Hardening expectations include:

• SRSExecutionUser characteristics:

  • Local user, not assigned to any group.

  • Denied local interactive and RDP login; allowed only to log on as a batch job.

  • Granted minimal filesystem permissions primarily on C:\Program Files\CyberArk\Management Agent\Workspace, with read/execute on the root and modify/write permissions on specific log and temporary subdirectories (for example Logs, tmp).

  • Password automatically reset by the Management Agent every two weeks.

• CyberarkManagementAgent account is granted the “Replace a process level token” permission and related rights needed by the agent while still respecting OS hardening baselines.

• Overall connector hardening must be configured to allow these operations; if local GPO or hardening baselines block such actions, SRS operations may fail.

Configuration model: policies, platforms, accounts

Master policy for secrets rotation

In Privilege Cloud, the master policy defines global defaults for secrets rotation intervals and verification behavior, which SRS uses as baselines.

Typical master policy parameters exposed in the UI include:

• Default rotation frequency (for example, 90 days).

• Default verification interval (for example, 7 days).

• Whether periodic rotation and verification are enabled.

• Whether users can override time frames (manual rotate/verify/reconcile at any time).

Platform‑level secrets rotation policies

Each platform (Windows, *NIX, cloud services, databases, web applications, etc.) has its own secrets rotation policy that SRS enforces.

The policy wizard typically configures:

• General settings:

  • Maximum secret rotation retries (0–10).

  • Minimum interval between retries (in minutes).

  • Rotation notice period (delay before performing rotation, allowing credential providers or consuming apps to sync).

• Automation settings:

  • Allow periodic rotation and verification, with platform‑specific intervals if overriding master policy.

  • Allow manual rotation, verification, and reconciliation on demand even outside scheduled windows when “Override time frames” is enabled.

• Linked accounts:

  • Default logon and reconcile accounts per platform.

  • Dependent accounts and platform‑level defaults that are automatically applied to new accounts.

Account‑level behavior and limitations

While SRS aims for consistent platform behavior, there are specific functionality considerations and limitations:

• Bulk rotation from the classic Privilege Cloud UI is not yet supported; administrators must either use APIs for account bulk rotation or perform operations platform by platform.

• Personal privileged accounts (self‑managed admin accounts created by IT administrators) are not supported by SRS.

• Certain legacy CPM behaviors (such as automatic secret change on check‑in under specific master policy combinations) have changed; for example, when exclusive access is enforced but one‑time password is not enabled, passwords may not be changed automatically after check‑in.

• New APIs replace some legacy CPM APIs, specifically around master policy and account secrets rotation; this matters for automation and integrations.

Installation and deployment

Prerequisites and planning

Because SRS is a SaaS backend, deployment focuses on connector infrastructure, Privilege Cloud tenant configuration, and platform migration rather than server installation.

Key prerequisites for an SRS‑ready environment:

• A Privilege Cloud tenant running a version that includes SRS (for example, Privilege Cloud v14.5 and later, where SRS is the recommended replacement for CPM in Privilege Cloud).

• At least two Windows connector servers per production environment for high availability and maintenance windows.

• Network connectivity:

  • Outbound HTTPS from connector servers to the CyberArk SaaS endpoints for Connector Management and SRS.

  • Connectivity from connector servers to target systems (RDP/WinRM/SMB, SSH, database ports, HTTP(S) APIs, etc., depending on platforms).

• OS dependencies:

  • Supported Windows Server versions for connector hosts (as specified for Connector Management and PSM).

  • .NET Framework 4.8 installed for plugins, especially for web application rotation.

  • Visual C++ Redistributable for certain plugin types; can be deployed automatically by SRS on first rotation unless disabled via API.

• Privilege Cloud identity and access configuration so that admins can authenticate and administer platforms, master policies, and connectors.

Step‑by‑step: Connector Management agent installation

The Management Agent is installed through the Connector Management interface.

A typical installation sequence:

1. Prepare connector host

   • Harden the Windows server according to CyberArk guidance, ensuring it still allows the required rights for SRSExecutionUser and CyberarkManagementAgent as documented in SRS hardening.

   • Install .NET Framework 4.8 and any prerequisite browser drivers if web application plugins will be used.

2. Add connector in Connector Management

   • In the CyberArk SaaS portal, open the service picker and select Connector Management.

   • On the Connectors page, click Add a connector.

   • In the Add connector wizard, define installation details:

     • Installation location: default is C:\Program Files, where the agent installs into C:\Program Files\CyberArk\Management Agent, or specify an alternative path.

     • Connector pool: assign the connector to a specific pool (for example, Prod‑OnPrem‑East) for HA and scoping.

3. Download and run installer

   • Download the connector installer package from the wizard.

   • Copy it to the connector host and run as Administrator.

   • Accept defaults or adjust installation path if required (must match the wizard setting).

4. Registration and connectivity checks

   • During installation, the agent performs connectivity tests to the SaaS service and registers back with Connector Management; this can be seen in the installation UI and logs under the Management Agent workspace path.

   • After completion, verify that the connector appears as Checked‑in / Active in Connector Management.

5. Install additional connectors (optional)

   • For environments with SIA or multiple networks, repeat the process for additional connector hosts, joining them to the same pool or different pools as required for segmentation.

Step‑by‑step: Enabling and using SRS in Privilege Cloud

Once connectors exist, SRS usage is mostly configuration‑driven:

1. Configure master rotation policy

   • In Privilege Cloud Portal, go to Administration > Platform Management.

   • Locate the Master rotation policy section and set defaults such as:

     • Rotation frequency (for example, 90 days).

     • Verification interval (for example, 7 days).

     • Whether periodic rotation and verification are enabled.

2. Configure platform secrets rotation policies

   • Still under Platform Management, select the relevant platform category (Windows, *NIX, Cloud Service, Database, Web Application, etc.).

   • Choose a platform and click More options > Edit, then use the Rotation policy tab to set:

     • Maximum rotation retries, minimum interval between retries.

     • Rotation notice period.

     • Automation flags (periodic rotation, manual rotation/verification/reconciliation).

     • Default logon and reconcile accounts and other linked accounts for the platform.

3. Verify platform plugins

   • Confirm that the platform has a supported rotation plugin associated (some older CPM‑only platforms may need migration to SRS plugin variants).

   • For custom or web application platforms, create or extend plugins as needed and verify that they are deployed to the connector cache on first rotation.

4. Onboard accounts and assign platforms

   • Onboard privileged accounts (Windows local/AD, Linux, DB, etc.) and assign them to appropriate platforms that are SRS‑enabled.

   • For each account, validate that the platform’s rotation policy and connector pool mapping allow reachability of the target.

5. Test and monitor rotation

   • Manually trigger rotation and verification from the account’s actions menu to validate connectivity and plugin configuration.

   • Inspect rotation status and version history on the Versions tab; SRS‑initiated rotations appear with appropriate annotations.

   • Verify errors through SRS/connector logs (see log section) and adjust policies or network configuration as needed.

Deployment changes and updates

New SRS‑related deployment behaviors include automatic deployment of Visual C++ Redistributable to connector machines on first rotation for plugins that require it, with optional API control to disable this behavior for organizations that manage this dependency themselves.

Configuration files and plugin artefacts

Plugin cache structure

On each connector, SRS caches its plugins under the Management Agent cache directory:

• Base path: C:\Program Files\CyberArk\Management Agent\Cache.

• Per‑platform folders: rotation_[platform]_[version], for example:

  • rotation_WindowsDomain_1.0.0

  • rotation_UnixSSH_1.0.3

Inside each platform folder, typical artefacts include:

• Plugin executables (for example, .exe, .dll) used to perform change/verify/reconcile.

• Policy/settings files controlling timeouts, prompts, or protocol options.

• Optional prompts/process files for terminal/web application automation, particularly for PMTerminal‑like or web‑based targets.

Editing guidance:

• Edits must be made on each connector that hosts the cached plugin.

• Changes remain local unless CyberArk Support updates backend plugin packages with your modified versions.

• Next rotation will use the edited cached plugin files; plugin redeployments from the backend (for example, upgrades) will overwrite local changes unless preserved.

Web application plugin configuration

For web application rotation plugins, additional configuration involves:

• Creating a driver folder: C:\Program Files\Cyberark\BrowserDrivers.

• Installing supported browsers such as Chrome and Edge at recommended versions (for example, Chrome 100+, Edge 103+).

• Installing matching browser drivers and configuring WebDriverUpdater.exe.config with PathToCPMDrivers pointing to the browser drivers folder, which SRS plugins also use in Privilege Cloud environments.

Connector Management configuration

The Management Agent installation path and workspace structure are defined during installation and visible in Connector Management. While most configuration is managed centrally, the following on‑disk locations are relevant:

• Installation root: C:\Program Files\CyberArk\Management Agent by default.[4]

• Workspace and component installation paths under workspace\component-installation-<random ID> for component and connector installation logs and temporary artefacts.

• Logs directory under Logs within the Management Agent folder (see below).

Logs and troubleshooting

Main log locations relevant to SRS

SRS itself is a SaaS service; its internal service logs are not directly accessible, but the following log sources on connector and related components are crucial:

• Management Agent main logs:

  • Location: C:\Program Files\CyberArk\Management Agent\Logs.

  • Content: Operational logs for the Management Agent and connector, including component installation, registration, and ongoing activities for modern services such as SRS and PSM.

• Component installation logs:

  • Location: C:\Program Files\CyberArk\Management Agent\workspace\component-installation-<random ID>\InstallationAutomation\<date>\.

  • Content: Logs for installation or upgrade of PSM and other components through Connector Management; relevant when verifying that connectors and dependent components are properly installed.

• Application‑level logs for legacy components (for CPM and PSM in a standard connector environment):

  • CPM logs: <CPM Installation path>\CyberArk\Password Manager\Logs.

  • PSM ongoing logs: C:\Program Files (x86)\CyberArk\PSM\Logs.

While there is not a separate “SRS.log” documented, SRS interactions with connectors and plugins surface through the Management Agent logs and plugin‑specific logs under the Management Agent workspace/log subdirectories, which the SRSExecutionUser is allowed to write to.

Log usage patterns

When troubleshooting SRS rotations:

1. Start from the Privilege Cloud UI

   • Check the account’s rotation status, last error message, and platform policy.

   • Note timestamps and connector pool used.

2. Inspect Management Agent logs

   • On the relevant connector host, inspect logs under C:\Program Files\CyberArk\Management Agent\Logs for entries around the failure time; look for job IDs and plugin failure messages.

3. Inspect plugin‑specific logs

   • For complex plugins (for example web application plugins), additional logs may exist in workspace subdirectories (Logs, tmp) or in platform‑specific folders, as described in plugin documentation.

4. Correlate with target‑side logs

   • Use OS or application logs on the target systems (for example, Windows Security Event Log, Linux syslog, database audit logs) to verify connection attempts and error details.

Vault and audit logs

All rotations, successful or failed, are recorded in the Vault’s audit logs and Privilege Cloud audit trail.

• Vault logs are accessible through PrivateArk or integrated SIEM pipelines and reflect events such as password changes and account property updates.

• When sending logs to external SIEM (for example, Google Security Operations), ingestion guidance specifies access to Vault Server conf and log folders on the Vault host.

CPM vs SRS – detailed comparison

Conceptual differences

Functional comparison and limitations

Key functional considerations when comparing CPM and SRS:

• Account coverage:

  • CPM: Supports broad ranges of accounts defined in on‑prem deployments across many platforms.

  • SRS: Aims to become the standard for Privilege Cloud; some legacy or niche platforms may still use CPM until equivalent SRS plugins are available.

• Bulk operations:

  • CPM: Supports bulk rotation through classic UI and internal scheduling.

  • SRS: Bulk rotation is currently limited to REST API for account bulk rotation; classic UI selection of multiple accounts for change is not yet supported.

• Personal privileged accounts:

  • CPM: Supports IT admins creating personal privileged accounts in some deployment models.

  • SRS: Does not support personal privileged accounts.

• Behavioral changes:

  • Certain master policy combinations behave differently; for example, exclusive access without one‑time password does not trigger automatic check‑in password changes in SRS.

• APIs:

  • SRS introduces new APIs for master policy and account secrets rotation, superseding CPM‑specific APIs.

Operational pros and cons

Advantages of SRS over CPM:

• No CPM server deployment, patching, or lifecycle management; rotation engine is fully SaaS‑managed.

• Connector‑based architecture simplifies routing to segmented networks by deploying additional connectors instead of additional CPMs.

• Improved scalability for large account sets; rotation jobs can be parallelized across connectors and backed by auto‑scaled SaaS infrastructure.

• Modern UI and API interfaces for defining secrets rotation policies, linked accounts, and viewing real‑time rotation state.

• Centralized plugin lifecycle for SRS, with plugins deployed on demand and updated centrally rather than per‑CPM server.

Advantages of CPM in some scenarios:

• Mature coverage and behavior for legacy, on‑prem Self‑Hosted deployments; many organizations have deeply tuned CPM policies and custom plugins.

• Some UI capabilities, such as classic bulk rotation operations, are more fully realized in CPM‑based workflows today versus early SRS UI capabilities.

• Personal privileged accounts and some niche platforms may still depend on CPM until equivalent SRS coverage is complete.

When to choose SRS vs CPM

When to prioritize SRS:

• New Privilege Cloud deployments where SRS is the recommended and default rotation engine.

• Organizations seeking to reduce on‑prem server footprint and operational overhead, preferring SaaS‑based services and connector‑only footprints.

• Environments with many accounts across multiple regions or networks where connector pools and SaaS scaling can simplify architecture.

• Teams investing in modern automation, REST APIs, and CI/CD‑driven secrets management.

When to retain or mix in CPM:

• Existing large CPM deployments on Self‑Hosted PAM where migration to SRS would be multi‑year and SRS is not available as a backend (SRS is currently positioned primarily with Privilege Cloud).

• Platforms or use cases not yet fully supported by SRS (for example, certain legacy protocols or personal privileged accounts).

• Transitional phases where both engines run side‑by‑side and low‑risk platforms/accounts are gradually migrated to SRS, as commonly recommended by practitioners.

A pragmatic strategy is to keep CPM for legacy and edge cases while migrating mainstream Windows, *NIX, and cloud platforms in Privilege Cloud to SRS, validating rotation quality and capacity stepwise.

Design and architecture guidance for SRS deployments

Connector and pool design

Architects should design connector infrastructure around network topology, availability targets, and workload.

Key recommendations:

• At least two connectors per critical pool to avoid single points of failure and to allow patching without downtime.

• Separate pools per network zone (for example, DMZ, internal, specific regions) so that SRS can route jobs to connectors with appropriate reach and to avoid cross‑zone traffic where undesired.

• Align PSM and SRS connectors where possible so that session isolation and secrets rotation use similar connectivity paths, simplifying firewall rules and troubleshooting.

• Capacity considerations:

  • Estimate maximum concurrent rotations and verification operations by account type.

  • Match connector sizing (CPU, RAM, network throughput) to expected workloads, especially for plug‑ins that execute heavy web automation or multi‑step scripts.

Policy design

Policy design in SRS is a balance between security goals (short rotation intervals, frequent verification) and operational stability.

Considerations:

• Use master policy defaults aligned with corporate standards (for example, 30–90 day rotation, 7–14 day verification) and then tailor platform policies for high‑risk accounts such as domain admins or break‑glass accounts.

• Use Rotation notice period to coordinate with credential providers and applications that cache credentials; longer notice periods help avoid outages for tightly coupled systems.

• Set conservative Maximum rotation retries and Minimum interval between retries to avoid thrashing a problematic target; use monitoring and alerting to detect repeated failures.

• Explicitly design linked accounts (logon/reconcile) per platform so that SRS can recover from drift or out‑of‑band changes.

Security and hardening

Security posture around SRS depends heavily on connector hardening and the management of plugin execution environments.

Main points:

• Treat connectors as high‑value assets equivalent to CPM servers; apply OS hardening, patching, and least privilege while still allowing documented SRSExecutionUser and CyberarkManagementAgent rights.

• Restrict local access to connector servers and Management Agent directories; only SRS and connector service accounts should write to plugin caches and logs.

• For web application plugins, maintain browser and driver versions in lockstep to avoid automation failures; use WebDriverUpdater where possible to automate this.

• Monitor connector logs centrally (for example, via log shipping to SIEM) to detect repeated rotation failures, unusual plugin behavior, or unexpected connectivity issues.

Migration strategy from CPM to SRS

A structured migration path for Privilege Cloud customers might include:

1. Assessment

   • Inventory platforms and accounts currently managed by CPM and identify those fully supported by SRS plugins.

   • Identify special cases (personal privileged accounts, niche platforms, highly customized plugins) to defer or re‑engineer.

2. Connector enablement

   • Deploy and validate connector pools sized for SRS workloads.

   • Confirm that PSM and other services are not adversely affected by connector re‑use or re‑allocation.

3. Pilot migration

   • Select low‑risk platforms (for example, non‑production Windows local accounts) and enable SRS‑backed rotation.

   • Run both CPM and SRS in parallel where appropriate, disabling CPM rotation for accounts moved to SRS.

4. Phased expansion

   • Gradually migrate core platforms and business‑critical accounts, monitoring rotation success rates and performance.

   • Use REST APIs and automation to bulk onboard accounts to SRS where UI features lag.[18][11]

5. Decommissioning and cleanup

   • Once confidence is high and coverage is adequate, decommission CPM servers for Privilege Cloud or reduce their role to edge platforms only.

Practical tips and patterns for CyberArk architects

• Design for failure visibility: Build dashboards or SIEM queries around SRS‑related events and connector logs so rotation failures are detected and triaged quickly.

• Standardize platform templates: Use consistent platform policies and linked accounts across environments (dev/test/prod) so SRS behavior is predictable when moving workloads.

• Leverage APIs early: Because some bulk operations are API‑only in SRS, incorporate REST calls into onboarding and maintenance pipelines from the start.

• Keep plugins close to source: Track any local plugin edits under source control, coordinate with CyberArk Support for long‑term plugin updates, and document which connectors hold custom versions.

• Plan concurrency carefully: Particularly for fragile legacy systems, cap simultaneous rotations and stage policies to avoid overloading targets.

***If this guide helped you design, fix, or simply better understand CyberArk SRS and you want to support more deep-dive content like this, you can do that here:
***Buy Me A Coffee