CARTN ← Back to site

Administrative & Privileged Account Documentation

Version 1.0.0 Last updated 2026-07-28 ⇩ Machine-readable version (JSON)

Overview

FedRAMP Authorization ID: FR2628943664

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.

This guide is publicly available, versioned, and accompanied by a machine-readable JSON export of every setting and control described below, so customers and third-party tools can programmatically compare recommended and default configurations against the current state of their tenant. See Document Version & Machine-Readable Format for details.

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 Recommended Configuration
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. Enforce MFA for all users. Require phishing-resistant MFA (FIDO2/WebAuthn) for any account assigned to a Global/Tenant Admin or Site/Location Admin role. Note: Xfinion will not activate a customer's CARTN federation until MFA enforcement is confirmed.
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. Limit Global/Tenant Admin group membership to the minimum number of individuals required. Use Site/Location Admin roles for facility-scoped personnel. Certify group memberships at least quarterly and remove stale assignments promptly.
Session Lifetime / Idle Timeout Excessively long Okta session lifetimes increase the window during which a stolen session token can be exploited. CARTN respects the session lifetime enforced by Okta and does not independently re-authenticate users. Set idle session timeout to 15 minutes or less for accounts assigned to administrative roles. Maximum absolute session lifetime should not exceed 8 hours. Apply a separate, stricter sign-on policy to users in CARTN admin-mapped groups.
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. Restrict the CARTN Okta application to managed, compliant devices and known corporate IP ranges. Enable device trust for privileged role holders. Apply network zone restrictions where feasible.
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. Integrate Okta with the organization's HR system to enable automated deprovisioning. Establish a same-day offboarding process that removes departing employees from all CARTN-linked Okta groups and deactivates their 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. An "all users" assignment must not be used for CARTN. Transmitting unnecessary claims increases data exposure and may cause unintended privilege grants. Assign the CARTN Okta application to named groups only; never use "Everyone" or "All Users." Transmit only the group-membership claim required by CARTN and omit all unnecessary attributes. Confirm assertion signing is enabled and the signing certificate is rotated on schedule.

Secure by Default

The following table documents the security controls that CARTN enforces by default, without any required action from the customer. Xfinion takes ownership of customer security outcomes: customers are not required to perform additional hardening or undertake complex configuration to reach a secure baseline. Controls marked as not customer-configurable are managed exclusively by Xfinion and cannot be weakened by any customer administrator or end user. Controls delegated to the customer’s Okta environment are listed with the minimum configuration Xfinion requires before federation is activated.

This table serves as CARTN’s Secure by Default reference and should be used alongside the security settings matrices in the sections above when assessing the platform’s baseline security posture.

Security Control Default State Configurable By Security Implication if Changed or Absent
Encryption at Rest Enabled (AES-256) Not customer-configurable All customer data at rest is encrypted by default using AES-256. Key material is managed through Xfinion's key management service with dual-control procedures. Disabling or weakening this control is not possible without Xfinion security team authorization.
Encryption in Transit Enforced (TLS 1.2+) Not configurable All API and web traffic is encrypted using TLS 1.2 or higher. Older protocol versions and unencrypted HTTP are rejected at the platform edge. This control is enforced at the infrastructure level and cannot be relaxed by any account class.
Audit Logging Enabled & Immutable Xfinion only (destination and retention period) Security-relevant logging is enabled by default and covers authentication events, role assignment changes, administrative configuration actions, asset tracking operations, and integration activity. Log records are written to a write-protected destination; no administrative account can modify or delete entries after they are written. Logs are retained for a minimum period consistent with FedRAMP Low requirements and the tenant’s configured data retention period. Disabling or truncating logging eliminates the evidentiary record required for incident response and compliance validation.
MFA for CSE (Top-Level Admin) Accounts Enforced Not customer-configurable MFA enrollment is required before any top-level administrative access is granted. Microsoft Authenticator or a hardware FIDO2 token is required. This control cannot be waived for any CSE account and applies regardless of network location.
Network Access Restriction for Admin Interfaces Enforced (VPN / Azure Bastion) Not customer-configurable CARTN administrative interfaces are not internet-reachable. A VPN or Azure Bastion session authenticated with Azure AD credentials and MFA is required. Removal of this control would expose infrastructure management interfaces to unauthenticated network access.
Just-in-Time Privilege Elevation (PIM) Enabled Xfinion only CSE elevated permissions are granted on a just-in-time basis for the duration of a specific task and expire automatically. Standing elevated access is prohibited. Disabling PIM would increase persistent privilege exposure for all CSE accounts.
Role-Based Access Control (via Okta Federation) Enforced CSE (federation mapping) + Customer (Okta group assignment) All CARTN access requires a valid Okta assertion containing an authorized group claim. No anonymous, credential-based, or direct database access is permitted. CARTN does not maintain an internal user credential store; authentication is entirely delegated to the customer's Okta IdP.
No Default Passwords / No Internal Credential Store Eliminated by design Not configurable CARTN does not maintain an internal user credential store and does not issue, accept, or store passwords for end users. All authentication is handled exclusively through the customer’s Okta IdP via SAML 2.0 or OIDC. The absence of a credential store eliminates the risk of default or weak passwords granting unauthorized access. Customers cannot configure CARTN to accept credential-based authentication outside of the federated Okta flow.
MFA Prerequisite for Federation Activation Enforced as activation gate Xfinion (activation gate) Xfinion CSEs will not activate a customer's CARTN SAML/OIDC federation until the customer's Okta administrator confirms in writing that MFA is enforced for all users assigned to the CARTN application. This ensures the platform's MFA requirement is upheld even though authentication is delegated to the customer's IdP.
Least-Privilege Role Assignment (CSE) Enforced via approval workflow Xfinion only All CSE Azure AD role assignments require documented approval from a designated access approver. Roles are assigned at the minimum scope required and are reviewed periodically. Overly broad role assignments increase the blast radius of a compromised CSE account.
API Key Scoping Least privilege required by policy CSE (per provisioning request) API keys are not issued with wildcard or administrative scopes. Each key is scoped to the minimum permissions required for its integration and stored in a secrets manager. Long-lived, over-scoped, or plaintext-stored keys represent a persistent risk if compromised.
Shared Administrative Accounts Prohibited Not configurable Each CSE holds an individual named account. Shared accounts are prohibited to ensure attribution and accountability in audit logs. All top-level administrative actions are traceable to a specific individual by design.
Vulnerability Disclosure Policy (VDP) Published N/A Xfinion maintains a publicly available coordinated Vulnerability Disclosure Policy that authorizes good-faith security research and testing across all CARTN components, provides a clear reporting channel, and commits to not recommending legal action against good-faith researchers. The VDP ensures externally discovered vulnerabilities are reported and remediated in a structured, timely manner. See the Security Disclosure page for details.

Document Version & Machine-Readable Format

This guide is versioned, and every setting, default, and control described in the tables above is also published in a structured, machine-readable JSON file that mirrors this page. Customers and third-party compliance or configuration-monitoring tools can fetch admin-guide.json directly to programmatically compare Xfinion's documented recommendations and defaults against the current configuration of a tenant, without needing to parse this HTML page.

⇩ Download admin-guide.json

Version Date Summary
1.0.0 2026-07-10 Initial publication of the Secure Configuration Guide alongside its machine-readable JSON export.

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: