Administrative & Privileged Account Documentation

Security & Compliance — FedRAMP 20x Low  —  Last Updated: May 29, 2026

Overview

This document provides publicly accessible guidance for the secure lifecycle management of top-level administrative and privileged accounts within the CARTN platform. It is maintained by Xfinion Customer Success Engineers (CSEs) and satisfies the FedRAMP 20x Low requirement for documentation covering account access, configuration, operation, and decommissioning, as well as the security implications of settings available to each account class.

CARTN does not expose user-manageable security settings within the application itself. Security configurations related to identity and access are enforced at the platform level by Xfinion CSEs (for top-level administrative accounts) or delegated to the Customer's Identity Provider (for privileged Customer Admin accounts). This design ensures that security controls cannot be weakened by individual end users and that the platform's security posture remains consistent across all customer tenants.

Account Types

CARTN recognizes two classes of accounts addressed by this document:

Top-Level Administrative Accounts

Top-level administrative accounts are held exclusively by Xfinion Customer Success Engineers. These accounts grant privileged access to CARTN's underlying platform infrastructure, tenant management capabilities, and system-wide configuration. They are not visible to or operable by any customer or end user.

Access to these accounts requires authentication through Microsoft Azure Active Directory (Azure AD / Entra ID) with multi-factor authentication (MFA) enforced, and is further gated by a VPN or Azure Bastion session. These accounts are created, managed, and decommissioned solely by Xfinion's internal identity and access management processes.

Privileged Accounts (Customer Admin)

Privileged accounts are Customer Admin accounts provisioned within each customer's Okta Identity Provider (IDP). Customers federate their Okta tenant with CARTN via SAML 2.0 or OIDC. The Customer Admin is responsible for assigning users to the appropriate Okta groups, which in turn map to CARTN roles. CARTN does not maintain a separate credential store or manage user provisioning directly; those controls reside entirely within the customer's Okta environment.

CARTN supports three account tiers for customer-facing access:

Role Capabilities
Global / Tenant Admin Full administrative control over the customer's CARTN tenant: user role assignment, site and location management, integration configuration, and access to all asset and audit data across the tenant.
Site / Location Admin Scoped administrative access limited to a specific facility or site within the tenant. Can manage users and asset configurations only within their assigned scope.
Standard User Operational access to track, locate, and manage assets. No configuration or administrative permissions within CARTN.

Top-Level Administrative Account Lifecycle

Access

Top-level administrative access is granted only to authorized Xfinion Customer Success Engineers. The following controls are required before access is established:

  1. Identity provisioning. An Azure AD account is created for the CSE within Xfinion's corporate directory as part of the HR and security onboarding process.
  2. MFA enrollment. The CSE must enroll in multi-factor authentication — using Microsoft Authenticator or a hardware FIDO2 token — before any administrative access is permitted.
  3. VPN / Azure Bastion. Access to the CARTN infrastructure requires an active VPN or Azure Bastion session authenticated with the CSE's Azure AD credentials and MFA. Network-level controls prevent unauthenticated or unencrypted access to administrative interfaces.
  4. Role assignment. Administrative roles within Azure AD are assigned on a least-privilege basis, must be approved by a designated access approver within Xfinion, and are reviewed on a periodic basis.
  5. Privileged Identity Management (PIM). Where applicable, just-in-time (JIT) elevation is used so that elevated permissions are active only for the duration of a specific task, reducing standing privilege exposure.

Configuration

Once access is established, CSEs may configure the following platform-level resources. All configuration actions are logged to an immutable audit trail.

  • Provisioning new customer tenants, including IDP federation settings (SAML/OIDC metadata, attribute mappings, and group-to-role assignments).
  • Configuring system-wide settings such as data retention periods, encryption key management, and API endpoint behavior.
  • Managing service accounts and API keys used for system integrations and automated processes.
  • Establishing and updating alert and monitoring configurations within the CARTN operations stack.

Configuration changes to production systems follow a change management process that requires peer review and documented approval before deployment.

Operation

During the operational period of a top-level administrative account, CSEs are expected to:

  • Perform routine platform health monitoring, patching, and maintenance within defined maintenance windows.
  • Respond to security alerts, incidents, and customer-escalated issues using documented runbooks.
  • Conduct periodic access reviews to verify that administrative role assignments remain appropriate and adhere to least privilege.
  • Review audit logs for administrative actions and flag anomalous behavior for investigation.
  • Rotate service account credentials and API keys on a scheduled basis consistent with Xfinion's key management policy.

CSEs must not use top-level administrative accounts for tasks that can be performed with lower-privileged access. Shared administrative accounts are prohibited; each CSE holds an individual named account to ensure accountability and attribution in audit logs.

Decommissioning

When a CSE leaves Xfinion or no longer requires administrative access, the following steps are completed within one business day of the triggering event:

  1. Azure AD account disabled. The CSE's Azure AD account is immediately disabled, invalidating all active sessions and preventing new logins.
  2. VPN / Bastion access revoked. VPN certificates and Azure Bastion session permissions tied to the account are revoked.
  3. MFA tokens removed. All registered MFA methods are cleared from the account.
  4. Role and PIM assignments removed. All Azure AD administrative roles and PIM eligibility assignments are revoked.
  5. Service account credentials rotated. Any service accounts or API keys the CSE had access to are rotated as a precautionary measure.
  6. Audit log preservation. Logs associated with the decommissioned account are retained per Xfinion's log retention policy to support future forensic needs.

Security Settings Operable by Top-Level Administrative Accounts

The following security-relevant settings are within the scope of top-level administrative accounts. CSEs must understand the security implications of each before making changes.

Setting Security Implication
Customer Tenant Provisioning Incorrect tenant configuration — particularly malformed IDP federation metadata or overly permissive group-to-role mappings — can grant unintended users access to a customer's CARTN environment. Tenant settings must be validated against the customer's signed configuration agreement before activation.
IDP Federation (SAML / OIDC) Configuration Misconfigured SAML or OIDC settings — such as accepting assertions from untrusted issuers, disabling signature validation, or using weak encryption — can allow authentication bypass or token forgery. Federation metadata must be sourced directly from the customer's IDP administrator and verified before being applied.
API Key Management API keys grant programmatic access to CARTN data and integration endpoints. Long-lived or over-scoped keys represent a persistent risk if compromised. Keys must be scoped to the minimum required permissions, stored in a secrets manager (not in code or configuration files), and rotated on a defined schedule or immediately upon suspected compromise.
Data Retention Configuration Retention periods govern how long asset tracking data and audit logs are stored. Setting them shorter than required by a customer's compliance obligations may destroy evidence needed for audit or incident investigations. Setting them excessively long may conflict with data minimization requirements. Retention settings must be reviewed against contractual and regulatory obligations before modification.
Encryption Key Management Encryption keys protect customer data at rest. Loss or improper rotation of keys can result in irrecoverable data loss. Key material must be managed through Xfinion's designated key management service, with rotation performed per policy and dual-control procedures applied to all key lifecycle operations.
Audit Logging Configuration Audit logs provide the evidentiary record for security monitoring, incident response, and compliance validation. Disabling or truncating audit logging eliminates visibility into potentially malicious activity. Log destinations must be write-protected so that no administrative account can delete or modify log records after they are written.
Service Account Configuration Service accounts used for automated processes must operate under least-privilege principles. Over-privileged service accounts can be exploited to escalate access or exfiltrate data if compromised. Service accounts must not be shared with human users, and their credentials must be rotated on schedule or immediately upon personnel changes.

Customer Admin (Privileged) Account Lifecycle

CARTN does not directly provision, manage, or decommission Customer Admin accounts. All identity lifecycle management for privileged customer accounts is performed by the Customer within their Okta Identity Provider. CARTN federates with the customer's Okta tenant and honors the role assignments encoded in Okta groups. This design ensures that account governance remains within the customer's organizational boundary, subject to the customer's own security policies.

Access

Customer Admins gain access to CARTN as follows:

  1. The customer's Okta administrator assigns the user to the Okta group mapped to the desired CARTN role (Global/Tenant Admin or Site/Location Admin).
  2. The user authenticates to CARTN by initiating the Okta SSO flow from the CARTN sign-in page. CARTN does not maintain a separate credential store; authentication is handled entirely by Okta.
  3. Upon successful authentication, CARTN reads the user's group memberships from the Okta assertion and grants the corresponding role. No additional provisioning is required inside CARTN.

The security strength of this step depends on the MFA and session policies configured by the customer in their Okta tenant. Customers are strongly encouraged to enforce phishing-resistant MFA (e.g., FIDO2/WebAuthn) for all accounts that will hold administrative roles in CARTN.

Configuration

Configuration of Customer Admin accounts — including role assignment, group membership, MFA enforcement, and sign-on policies — is performed entirely within the customer's Okta environment. Xfinion provides documentation on the required Okta group-to-CARTN-role mapping and recommended Okta policy settings, but the customer's Okta administrator controls all access decisions.

Within CARTN, a Global/Tenant Admin can perform the following actions:

  • View and manage all users and their CARTN role assignments (sourced from Okta group membership).
  • Configure site and location structures within the tenant.
  • View tenant-wide audit logs and asset tracking history.
  • Manage integration settings for enterprise systems (ERP, ITSM connectors) within the options made available by Xfinion.

Operation

During normal operation, Customer Admins should apply the following practices:

  • Periodically review Okta group assignments to verify that only authorized personnel hold CARTN administrative roles.
  • Promptly remove departing employees from CARTN-linked Okta groups to prevent persistent access.
  • Limit Global/Tenant Admin assignments to the minimum number of individuals required, using Site/Location Admin roles for personnel whose responsibility is scoped to a specific facility.
  • Review CARTN audit logs for unexpected or unauthorized administrative actions.

Decommissioning

To decommission a Customer Admin account:

  1. The customer's Okta administrator removes the user from all CARTN-linked Okta groups. This terminates the user's administrative permissions in CARTN upon their next authentication or when their current session expires.
  2. For immediate revocation, the Okta administrator should also terminate the user's active Okta sessions from the Okta admin console.
  3. If the user is leaving the organization entirely, the Okta administrator should deactivate the user's Okta account, which prevents any further SSO-based access to CARTN and all other federated applications.

Customers who require immediate hard termination of a specific user's active CARTN sessions should contact Xfinion support at contact@xfinion.com. Xfinion can invalidate active CARTN sessions for a specific tenant on request.

Security Settings Operable by Privileged (Customer Admin) Accounts

Because CARTN does not expose user-manageable security settings within the application, all security-relevant settings operable by Customer Admins are configured in the customer's Okta Identity Provider. The following table describes each setting and its security implication for CARTN access.

Setting (Okta / IDP) Security Implication for CARTN Access
MFA Policy If MFA is not enforced in Okta, a compromised password is sufficient to gain CARTN access, including with administrative privileges. Customers must enforce MFA for all users who will access CARTN, and should require phishing-resistant MFA (FIDO2/WebAuthn) for accounts with Global/Tenant Admin or Site/Location Admin roles.
Okta Group-to-CARTN Role Mapping The Okta groups mapped to CARTN roles determine what permissions each user holds. Assigning too many users to the Global Admin-mapped group violates least privilege and increases the blast radius of a compromised account. Role-to-group mappings should be reviewed at least quarterly.
Session Lifetime / Idle Timeout Excessively long Okta session lifetimes increase the window during which a stolen session token can be exploited. Customers should configure session idle timeouts consistent with their security policy. CARTN respects the session lifetime enforced by Okta and does not independently re-authenticate users.
Conditional Access / Sign-On Policies Okta Sign-On Policies can restrict authentication to known IP ranges, managed devices, or specific geographic regions. Applying these restrictions to the CARTN Okta application reduces exposure from stolen credentials used from unexpected locations or unmanaged devices. Customers are encouraged to configure device trust and network zone policies for privileged role holders.
User Account Lifecycle (Deprovisioning) Failure to promptly deprovision departing employees from CARTN-linked Okta groups allows former employees to retain CARTN access, potentially at an administrative level. Customers should ensure that their HR offboarding process includes same-day removal from CARTN-linked Okta groups and deactivation of the Okta account.
SAML / OIDC Application Configuration The SAML or OIDC application configured in Okta for CARTN controls which assertion attributes and group claims are sent. The application should be restricted to assigned users and groups only; an "all users" assignment must not be used for CARTN. Ensuring that only required claims are transmitted limits data exposure and prevents unintended privilege grants.

Contact

For questions about this guidance, to report a suspected security issue, or to request immediate session termination for a customer account, contact Xfinion support: