Internal Use

Identification and Authentication Policy and Procedures

Dispel

Document Control

1. PURPOSE AND SCOPE

1.1 Purpose

This policy and procedures document defines how Dispel establishes and manages identification and authentication (I&A) for users, devices, and services accessing Dispel systems and the Dispel Zero Trust Engine.

1.2 Scope

This policy applies to:

• All Dispel workforce members, contractors, and third parties who access Dispel systems.
• All components of the Dispel Zero Trust Engine and supporting infrastructure.
• All identification and authentication mechanisms (passwords, MFA, keys, SSO, etc.).

1.3 Regulatory and Framework Alignment

2. POLICY STATEMENTS

2.1 Management Commitment

Management Commitment Statement

Senior Management at Dispel is dedicated to the protection of our information assets, industrial control systems, and Protected Health Information (PHI). We assume full accountability for the effectiveness of our security program, ensuring it is integrated into all business processes and aligned with our strategic goals. To maintain compliance with ISO 27001, IEC 62443, HIPAA, and NIST 800-53, we formally commit to:

• Resource Provisioning: Providing the necessary financial, technical, and human resources to sustain a robust security posture.
• Risk-Based Governance: Approving security policies and overseeing a continuous risk management process that prioritizes both data privacy and operational safety.
• Operational Resilience: Supporting the security of industrial automation and control systems (IACS) to ensure safety and reliability.
• Continuous Oversight: Conducting regular management reviews to evaluate program performance, audit results, and opportunities for improvement.

2.2 Primary Policy Statement

Dispel SHALL ensure that all users, devices, and services accessing Dispel systems and the Dispel Zero Trust Engine are uniquely identified and authenticated using approved mechanisms.

2.3 Secondary Policy Statement

• Multi-factor authentication SHALL be used for privileged and remote access where technically feasible.
• Identification and authentication requirements SHALL be aligned with applicable regulatory and contractual obligations.
• I&A mechanisms SHALL be managed throughout their lifecycle, including issuance, rotation, revocation, and recovery.

3. REQUIREMENTS

3.1 Governance, Covered Persons, and Review Tempo

Coordination Among Organizational Entities

NIST 800-53 Field: IA-1

The procedures described throughout this document cover where intra-organizational coordination is known to be necessary to effectuate the documented policies. If a Dispel employee finds a procedure no longer reflects the current dynamics within the organization, or a procedure should be revised to achieve the same effect more efficiently, they shall notify the Policy Owner of the recommended change.

The Policy Owner will ensure the high-level identification and authentication requirements for the system or system service are represented during relevant meetings for Dispel Zero Trust Engine business process planning.

The Policy Owner will include in their budget sufficient resources to enable identification and authentication to the system or system service. This budget will be reviewed and approved at least annually by the Dispel Board of Directors as part of the company capital planning and investment control process.

Covered Persons

NIST 800-53 Field: IA-1

All workforce members who are authorized to work on Dispel Zero Trust Engine instances are covered by this policy.

Dissemination, Acceptance, and Acknowledgement

NIST 800-53 Field: IA-1

The process of dissemination shall be made failsafe by holding, as a prerequisite to being authorized as a Covered Person, that an individual must first review, accept, and acknowledge this document. All Covered Persons must review, accept, and acknowledge this document at least annually.

Policy and Procedures Review Tempo

NIST 800-53 Field: IA-1

The Policy Owner must review and, if necessary, update policies and procedures:

1. At least once annually;
2. Policies following discretionary off-cycle formal policy reviews; and
3. Procedures following significant changes (as defined by the current revision of NIST SP 800‑37).

3.2 User Accounts and Profiles

User Accounts

NIST 800-53 Field: IA-2, IA-8

All Dispel Zero Trust Engine users must have unique identities and authentication. Dispel organizational identities are tied to corporate email addresses created by corporate identity providers. Non-organizational users or processes acting on behalf of non-organizational users must also be uniquely identified through their email address, preferably corporate. Customers are responsible for enforcing identifier uniqueness across their users [IA-8].

Each organizational user will have a unique identity in the account following the naming schema outlined in the User Naming and Authentication Standard. This is summarized as firstName@dispel.com or firstName.lastName@dispel.com (“Identity”). If the Identity already exists for another user, or is in the Reuse Cooldown Period, then the following name schema should be used: firstName.middleInitial.lastName@dispel.com. Each user must have a unique login using passwords to authenticate user identities and other authenticators such as Temporary One-Time Passwords (TOTP) for multi-factor authentication [IA-2]; specifics to this standard are also in the User Naming and Authentication Standard.

Identify User Status

NIST 800-53 Field: IA-4(4)

User accounts in the Dispel Identity Provider should identify the user type as either a Member or Guest user. Members are Dispel employees or function accounts, and guests are external users (e.g., contractors) who have a need for a Dispel account.

FedRAMP System Specific — Customers are responsible for identifying their users’ status on the Dispel Zero Trust Engine. Dispel recommends using Groups for contractors and foreign nationals to identify the user type and restrict their access [IA-4(4)].

Use Defined Profiles

NIST 800-53 Field: IA-8(4)

User profiles in the Dispel Zero Trust Engine, Dispel Identity Provider, and non-SSO systems must use identity, credentials, and access when defining the profile of each user. User accounts must be unique, identifiable to an individual or function, and erasable. Accounts must have unique credentials, employing MFA whenever possible. Access management ensures that only those permitted to access resources or perform specific actions on them (e.g., “view,” “share,” “edit”) can do so. The most restrictive state should be used, with the principle of least privilege applied to user accounts and during user access review audits.

The OpenID Connect Core [OpenID.Core] defined profile provides baseline identity information. Dispel uses attributes for given_name, family_name, address, and birthdate to be supported by iGov Providers if possible unless data quality requirements or privacy considerations prevent it. It is left to the OpenID Provider and the trust framework to set any further limitations on this profile data – see Privacy Considerations.

Profiles must be unique, identifiable to an individual or function, and erasable; with unique credentials, employing MFA whenever possible; and scoped to least privilege. Customers are responsible for defining profiles, including FICAM-issued profiles, in and for the Dispel Zero Trust Engine using SSO, groups, and appropriate privilege assignment [IA-8(4)]

3.3 Authenticator Management and Authentication

Authenticator Management

NIST 800-53 Field: IA-5

Scope-specific authenticator management is described below. Authenticators by default (memorized passwords) fall under the User Naming and Authentication Standard, with system‑seeded secrets managed under the Secrets Management Standard.

Web Application

The DZTE Web Application Dashboard manages authenticators in accordance with the DZTE User Guide. The process is automated and initiated by the customer to allow users and administrators into the web application system. The general flow is:

1. An authorized administrator establishes the user.
2. The user receives an email with a tokenized link to set a username/password and MFA.
3. The user logs in and establishes an authenticator.

The detailed process is described in the user guide.

Customer Network

The DZTE Web Application can manage Customer Network authenticators for “one-time use” sessions. The generalized flow (with details in the User Guide) is:

1. An authorized user logs into the DZTE Web Application Dashboard and requests an access window on the Customer Network.
2. An authorized Administrator approves access requests and establishes access control rules for the scope of the requested session.
3. An authorized user then reserves the Virtual Desktop for the session, which triggers instantiation of the session.
4. Once the session is established, the authenticator is passed to the user in the Web Application Dashboard in the form of a one‑time password and user for that Virtual Machine session.
5. After the session, the Virtual Machine (and authenticator) is destroyed.

Cloud and Infrastructure

All administrative actions are within the Dispel Organizational Systems Access Request System, which governs account request, authorization, creation and management of authenticators, and access control.

FedRAMP System Specific – Dispel user authenticators must change at the same frequency set by the Customer on the Dispel Zero Trust Engine. SP 800‑63B §5.1.1.2 paragraph 9 states:
“Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.”

Authentication

NIST 800-53 Field: IA-5(8)

A single-user authentication domain is used to authenticate users in the Dispel Zero Trust Engine. All users authenticate within the central Dispel Zero Trust Engine authentication service or through federated SSO [IA‑5(8)].

Password-Based Authentication

NIST 800-53 Field: IA-5(1)

Note: Password creation, complexity, user obligations, and storage requirements are defined in the Password Policy (P-PasswordPolicy), which is the authoritative source for password-specific implementation. This section covers system-level password authentication configuration and integration.

Password-based authentication applies to passwords regardless of whether they are used in single‑factor or multi‑factor authentication.

• All Dispel employees are encouraged to use password vaults to maintain long unique passwords and to check that passwords are not compromised or re‑used. Dispel maintains a list of commonly used, expected, or compromised passwords and updates the list daily and when organizational passwords are suspected to have been compromised directly or indirectly [IA‑5(1)(b)].
• Passwords should only be sent over cryptographically‑protected channels (e.g., TLS). This is enforced by policy and training (never log into sites without TLS) and through protection in 1Password. 1Password warns users against authenticating over unsecured sites such as HTTP. The Dispel Zero Trust Engine operates using TLS 1.2 [IA‑5(1)(c)].
• Dispel’s 1Password vault stores passwords in AES‑GCM‑256 authenticated encryption. Encryption keys, initialization vectors, and nonces are all generated using cryptographically secure PRNGs. 1Password uses PBKDF2‑HMAC‑SHA256 for key derivation. User account passwords in the Dispel Zero Trust Engine are hashed using Argon2 before being stored [IA‑5(1)(d)].
• If a user forgets their password or needs help recovering access to their 1Password account, they are automatically prompted to reset their password upon account recovery. If a user forgets their password or needs help recovering access to their account on the Dispel Zero Trust Engine, they must reset their password as a mandatory account recovery step [IA‑5(1)(e)].
• 1Password enables and encourages selection of long and complex passwords through automated password generation (up to 100 characters, with numbers, symbols, and characters). The Dispel Zero Trust Engine supports passwords up to 128 characters, with printable ASCII characters [IA‑5(1)(f), IA‑5(1)(g)].
• Minimum password requirements of 14 characters are enforced by policy in 1Password for vault access [IA‑5(1)(h)].
• In the Dispel Zero Trust Engine, authenticators are set by the user during initial account creation. No default authenticators are issued; users must always set a new authenticator [IA‑5(b)]. The system enforces minimum authenticator requirements [IA‑5(c)]:
  • Length between 14 and 128 characters.
  • At least 1 uppercase, 1 special character, and 1 number.
  • Customers can additionally enforce: MFA, password history, min/max lifetime, inactivity lockout, and temporary lockout after consecutive failed attempts.
• FedRAMP Specific – In the DZTE, group or role accounts are based on individual identities. Group accounts accessed by Dispel employees are prohibited [IA‑5(i)]. Customers are responsible for setting policies and justifications for group accounts if they choose to use them.

Multi-Factor Authentication

NIST 800-53 Field: IA-2(1), IA-2(2), IA-2(6)

All Dispel employees must have MFA as part of the authentication process when accessing an internal system.

• Administrators shall enforce the use of MFA or document mitigations and track the risk in the Risk Management Process.
• Customers utilizing SSO are responsible for their MFA systems.
• FedRAMP System Specific – Dispel Zero Trust Engine supports multi-factor authentication for network and remote access (local is not possible) to privileged and non‑privileged accounts. Dispel System Administrators use FIPS 140‑2 (Overall Level 1/2, Physical Security Level 3) hardware tokens for MFA (e.g., YubiKey 5 FIPS Series) [IA‑2(6)(a)]. Customers ensure their users' MFA device is separate from the system gaining access [IA‑2(6)(b)].

Phishing Resistance

NIST 800-53 Field: IA-2

1Password supports phishing resistance for passwords and multi‑factor authentication through channel binding in alignment with NIST SP 800‑63B §5.2.5.1 through the use of passkeys. When possible, Dispel employees should use passkeys on supported websites.

The Dispel Zero Trust Engine supports FIDO2 phishing‑resistant MFA tokens. Customers are responsible for requiring their users to employ FIDO2 hardware tokens for MFA. Dispel supports enforcement by allowing customers to mandate MFA for all users in the Dashboard’s Settings section [IA‑2].

Public Key-Based Authentication

NIST 800-53 Field: IA-5(2)

Public key cryptography is a valid authentication mechanism for individuals, machines, and devices. For PKI solutions, status information for certification paths includes certificate revocation lists or certificate status protocol responses.

When public key encryption is used for infrastructure:

• Private keys must be stored in 1Password.
• Vault access to the private key must be restricted to the account of the individual or group.
• If group access is used, all individuals with access to the private key must be identified in 1Password.

When PKI is used, certificate paths must be verified using the DigiCert trust anchor and certificate chain.

FedRAMP System Specific – Users do not authenticate with the Dispel Zero Trust Engine using public key‑based authentication [IA‑5(2)].

3.5 Additional IA Controls

Cryptographic Module Authentication

NIST 800-53 Field: IA-7

FedRAMP System Specific – Cloud‑native cryptographic modules are utilized for the DZTE, and authentication for the system is inherited from the cloud providers according to least privilege and segregation of duties, as defined in the Org Systems Access Request Process Guide and the Secrets Management Standard.

Replay Attack Prevention

NIST 800-53 Field: IA-2(8)

Dispel shall select services that support the prevention of replay attacks through time‑based authentication. Protection methods include time‑synchronous or cryptographic authenticators. Authentication protection should be evaluated during procurement.

The Dispel Zero Trust Engine includes replay attack prevention, including time‑synchronous and cryptographic authenticators tied to session tokens issued by the API to the user’s device during authentication [IA‑2(8)]. The general mechanism is achieved by using session tokens issued in a time‑based manner or TOTP tokens to enhance sessions that are not token‑based.

Authentication Feedback

NIST 800-53 Field: IA-6

The Dispel Zero Trust Engine obscures feedback of authentication information during the authentication process to prevent others from observing credentials. This includes using techniques such as displaying asterisks when users type passwords. [IA‑6]

4. ROLES AND RESPONSIBILITIES

4.1 Policy Owner (Chief Technology Officer or Delegate)

Responsibilities:

• Owns this Identification and Authentication policy and procedures.
• Manages development, documentation, and dissemination of the policy.
• Ensures high‑level identification and authentication requirements are represented in relevant business process planning for the Dispel Zero Trust Engine.
• Includes sufficient resources for I&A in annual budgets and presents them to the Board for review and approval.

4.2 Chief Technology Officer (CTO)

Responsibilities:

• Serves as responsible role for IA controls including (non‑exhaustive):
  IA‑1, IA‑2, IA‑2(1), IA‑2(2), IA‑2(5), IA‑2(8), IA‑5(7), IA‑5(8), IA‑6, IA‑7, IA‑8, IA‑8(2), IA‑11.
• Oversees design and implementation of I&A mechanisms for Dispel systems and the Dispel Zero Trust Engine.
• Ensures MFA, phishing‑resistant authenticators, and PKI usage align with NIST and FedRAMP requirements where applicable.
• Ensures device identification and encrypted inter‑component communication are implemented and maintained.

4.3 Security Officer

Responsibilities:

• Serves as responsible role for relevant IA‑5 controls (e.g., IA‑5, IA‑5(1), IA‑5(2), IA‑5(6)).
• Defines authenticator strength, lifecycle, and reset policies.
• Ensures password policies and vault practices (e.g., 1Password usage) are implemented and monitored.
• Coordinates response when authenticators are suspected or confirmed compromised.

4.4 Compliance Officer

Responsibilities:

• Serves as responsible role for IA‑2(6) where applicable and as co‑owner of identity proofing requirements (IA‑12 and its enhancements).
• Ensures background checks, I‑9 verification, and eVerify processes are in place and aligned with identity proofing requirements.
• Coordinates audits of I&A controls and maintains evidence for internal and external assessments.

4.5 Head of Operations / System Owner

Responsibilities:

• Serves as responsible role for IA‑4 and IA‑4(4), including user identifier management and distinguishing member vs guest accounts.
• Ensures operational enforcement of account naming, uniqueness, and profile configuration.
• Works with the CTO and Security Officer to ensure system configurations support I&A policy.

4.6 Customers (for Dispel Zero Trust Engine)

Responsibilities:

• Enforce identifier uniqueness and user status (member/guest) across their users [IA‑8, IA‑4(4)].
• Define and manage user profiles, including FICAM‑issued profiles, in their IdP and in the Dispel Zero Trust Engine [IA‑8(4)].
• Operate and maintain their own MFA and PKI infrastructure where federated authentication is used.
• Perform identity proofing and onboarding for their users in accordance with their own policies and regulatory requirements, using DZTE tools where applicable.

4.7 All Covered Persons

Responsibilities:

• Comply with this Identification and Authentication policy and all related procedures.
• Protect their authenticators (passwords, tokens, keys, devices) from unauthorized disclosure or use.
• Report suspected compromise of authenticators or identity data promptly to the Security Officer and/or Policy Owner.

5. PROCEDURES

NOTE: This section intentionally references the detailed requirements in Section 3. When we normalize this document fully, we will promote the most important stepwise flows (e.g., onboarding, authenticator reset, DZTE session provisioning) into explicit tables below.

5.1 Identification and Authentication Lifecycle (High-Level)

6. MONITORING AND COMPLIANCE

6.1 Compliance Monitoring

Compliance with this Identification and Authentication Policy and Procedures SHALL be monitored through:

• Technical monitoring of authentication events in the Dispel Zero Trust Engine and supporting identity providers, including:
  • Failed authentication attempts and lockouts.
  • Use of MFA and phishing‑resistant authenticators where required.
  • Unusual login patterns or geographic anomalies.
• Periodic access reviews of:
  • Covered Persons’ access to Dispel systems.
  • Customer user access to DZTE environments, where Dispel has visibility.
  • Use of group or shared accounts in customer environments, where applicable.
• Control assessments and audits, including internal audits and external assessments (e.g., SOC 2, ISO 27001, FedRAMP, HIPAA‑related engagements) that test the effectiveness of I&A controls listed in Section 1.3.

Findings from monitoring activities SHALL be tracked through the risk and issue management process and remediated within defined timeframes based on risk.

6.2 Metrics and Reporting

The following metrics SHALL be tracked and, at minimum, reviewed quarterly by the Policy Owner and Security Officer:

Additional metrics MAY be defined as needed to satisfy specific regulatory, contractual, or customer requirements.

6.3 Non-Compliance Consequences

Failure to comply with this policy and its procedures may result in:

• For Covered Persons (Dispel workforce and contractors):
  • Revocation or restriction of system access.
  • Corrective actions up to and including disciplinary action, in line with Dispel HR policies and applicable law.
• For Customers and Third Parties:
  • Suspension or limitation of access to the Dispel Zero Trust Engine where non‑compliance creates material risk.
  • Contractual remedies as defined in the applicable agreement (e.g., requirement to implement MFA, identity proofing, or other controls before access is restored).
• For all parties:
  • Escalation to senior management and, where appropriate, inclusion in risk registers, audit findings, and corrective action plans.

7. EXCEPTIONS AND WAIVERS

7.1 Exception Process

Exceptions to this Identification and Authentication Policy and Procedures SHALL:

1. Be submitted in writing by the requesting party (Covered Person, system owner, or customer).
2. Clearly identify the specific policy or procedural requirement(s) for which an exception is requested (e.g., MFA enforcement, password complexity, device identification).
3. Include detailed justification, including:
   • Business need and benefits.
   • Technical feasibility constraints, if any.
   • Impact on confidentiality, integrity, and availability.
4. Describe compensating controls or mitigation measures that will be implemented to manage the residual risk (e.g., additional monitoring, time‑bound access, manual reviews).
5. Define the exception duration (start and end date) and a remediation or sunset plan.
6. Be reviewed by the Policy Owner and Security Officer, with input from the Compliance Officer where regulatory requirements are implicated.

Approved exceptions SHALL be documented in an exceptions register and reviewed at least annually or upon significant change to underlying systems, threats, or requirements.

7.2 Exception Approval Authority

8. DEFINITIONS

Authenticator: A mechanism used to verify the identity of a user, device, or process (e.g., password, cryptographic key, token, passkey, or multi‑factor authentication device).

Covered Person: Any Dispel workforce member, contractor, or third party who is authorized to access Dispel systems or manage Dispel Zero Trust Engine environments.

Identity Proofing: The process of verifying that a claimed identity is valid and belongs to the person presenting it, using evidence such as government‑issued identification, background checks, and employment eligibility verification.

Multi-Factor Authentication (MFA): An authentication approach that requires two or more independent authentication factors (e.g., something you know, something you have, something you are) to establish confidence in a user’s identity.

Phishing-Resistant Authentication: An authentication mechanism designed to prevent successful phishing attacks, such as FIDO2‑based hardware tokens or passkeys that bind authentication to the legitimate relying party.

Dispel Zero Trust Engine (DZTE): Dispel’s platform providing zero trust network access and related services to customers.

Additional definitions MAY be added as needed to support clarity for readers and auditors.

9. REFERENCES

9.1 Internal References

• System Access Control Policy
• Password Policy
• User Naming and Authentication Standard
• Secrets Management Standard
• Org Systems Access Request Process Guide
• Risk Management Policy and Procedures
• Incident Response Policy and Procedures

9.2 External References

• NIST SP 800‑53, Security and Privacy Controls for Information Systems and Organizations (IA family)
• NIST SP 800‑63 Digital Identity Guidelines (63‑A, 63‑B, 63‑C)
• ISO/IEC 27001 and ISO/IEC 27002 (access control and identity management controls)
• IEC 62443 series (industrial automation and control systems security)
• HIPAA Security Rule (45 CFR Part 164, Subpart C)
• FedRAMP requirements and relevant agency overlays (where applicable)

10. DOCUMENT HISTORY

11. APPROVAL SIGNATURES

APPENDICES

Appendix A: Supporting Identification and Authentication Procedures

This appendix may include:

• Detailed onboarding and offboarding checklists for Covered Persons.
• Step‑by‑step procedures for:
  • Account creation, modification, and termination.
  • Authenticator issuance, rotation, revocation, and recovery.
  • DZTE session provisioning and one‑time access workflows.
• Screenshots or configuration examples for IdP, MFA, and DZTE settings, where appropriate.

Appendix B: Additional Guidance and Examples

This appendix may include:

• Example configurations illustrating strong MFA and phishing‑resistant authentication.
• Sample communications to users about password practices, MFA enrollment, and identity proofing requirements.
• Links or references to current NIST, ISO, and regulatory guidance relevant to I&A.## APPENDICES