Authentication Policy

This Authentication Policy ("Policy") describes authentication requirements for access to the Services and related MiseCentral systems. This Policy applies to Authorized Users, Customer administrators, MiseCentral personnel, Partner Users, and non-human credentials where authentication mechanisms are supported.

Capitalized terms not defined herein have the meanings set forth in the MiseCentral Legal Library Defined Terms or the applicable Agreement.

1. Purpose and Scope

1.1. Purpose. MiseCentral implements authentication controls to verify the identity of users and systems before granting access to the Services, administrative functions, Support Mode, Partner Support Mode, and API endpoints.

1.2. Scope. This Policy covers:

(a) interactive user authentication to the Services;

(b) authentication for MiseCentral staff and Partner Users accessing operational and partner surfaces;

(c) authentication and authorization for API Clients and Service Accounts;

(d) session establishment, maintenance, and termination; and

(e) integration with organization multi-factor authentication requirements described in the MFA Policy.

2. Authentication Principles

2.1. Unique Identity. Each Authorized User, Partner User, and MiseCentral staff member is assigned a unique identity within the applicable identity lane. Shared personal accounts are prohibited.

2.2. Credential Confidentiality. Users must not share passwords, one-time codes, hardware tokens, or recovery credentials. MiseCentral personnel and Partners must never request Customer passwords and must not display or return credentials in assistance workflows.

2.3. Strong Credentials. Passwords, where used, must meet minimum complexity and length requirements displayed at enrollment and password change. MiseCentral may reject commonly compromised passwords.

2.4. Session Security. Authenticated sessions use industry-standard session management, including timeout after inactivity, secure cookie attributes where applicable, and server-side invalidation upon logout or credential reset.

2.5. Fail Secure. Authentication failures do not reveal whether a specific account exists beyond generic error messaging suitable for user experience and security balance.

3. Customer User Authentication

3.1. Primary Authentication. Authorized Users authenticate with a verified email or username and password, or with an authentication method enabled for the organization as described in Documentation.

3.2. Email Verification. New accounts and material account changes may require email verification before full access is granted.

3.3. Organization MFA. Customer organizations may configure MFA mandates as optional, required for administrators, or required for all members, as described in the MFA Policy. Authentication flows enforce organization policy after any applicable grace period.

3.4. Account Recovery. Self-service account recovery uses verified channels. Recovery flows are designed to resist unauthorized takeover. Customers should maintain current administrator contacts for organizational recovery scenarios.

3.5. Authorized User Responsibility. Customer is responsible for provisioning and deprovisioning Authorized Users, maintaining accurate contact information, and investigating suspicious login activity within their organization.

4. Multi-Factor Authentication Integration

4.1. Where organization MFA is required, users must enroll a supported second factor before completing authentication after the enforcement date, subject to grace period and lockout prevention rules in the MFA Policy.

4.2. MFA verification is required at login when mandated and may be required for sensitive in-session actions as described in Documentation.

4.3. Service Accounts may be exempt from organization MFA mandates when Customer enables exemption and the account is used solely for non-interactive integration, as described in the MFA Policy.

5. API and Service Account Authentication

5.1. API Clients. Programmatic access uses Customer-registered API Clients with client credentials or tokens scoped to authorized permissions. Credentials must be stored securely on Customer systems and rotated upon compromise or personnel change.

5.2. Service Accounts. Service Accounts authenticate through mechanisms described in Documentation, which may include token-based or key-based authentication distinct from interactive user login.

5.3. Rate Limiting and Anomaly Detection. API authentication endpoints and token use are subject to rate limiting and monitoring for abusive patterns.

5.4. Revocation. Customer administrators may revoke API Clients, Service Accounts, and active sessions at any time through organization administration tools.

6. MiseCentral Staff and Partner Authentication

6.1. MiseCentral personnel authenticate to internal systems using MiseCentral identity controls with MFA required for production access and Support Mode as described in the MFA Policy.

6.2. Partner Users authenticate to the Partner Portal using Partner identity controls with MFA required for Partner Support Mode as described in the MFA Policy.

6.3. Staff and Partner authentication is independent from Customer organization credentials. Support Mode and Partner Support Mode do not use Customer user passwords.

7. Connected Services Authentication

7.1. Connected Services authenticate to the Services using credentials, OAuth tokens, or other mechanisms authorized by the Customer administrator. Customers must review granted scopes and revoke access when integrations are decommissioned.

7.2. MiseCentral validates integration tokens on each request within authorized scope. Expired or revoked tokens are rejected.

8. Authentication Events and Monitoring

8.1. Authentication successes and failures, MFA enrollments, password resets, and session terminations generate security events logged as described in the Logging and Audit Policy.

8.2. Repeated failed authentication attempts may trigger temporary lockout or additional verification requirements.

8.3. Customer administrators may review authentication-related security events for their organization where exposed in Documentation.

9. Lockout and Recovery

9.1. Account lockout policies balance abuse prevention with availability. Organization MFA lockout prevention ensures administrators are not collectively locked out when MFA mandates are enabled, as described in the MFA Policy.

9.2. MiseCentral support may assist with authentication recovery through verified procedures that do not compromise credential confidentiality.

10. Policy Updates

10.1. MiseCentral may update authentication requirements to address evolving threats, regulatory expectations, or product capabilities by updating this Policy and Documentation.

10.2. Material changes affecting Customer authentication flows will be communicated through Documentation or in-product notice where practicable.

11. Contact

MiseCentral LLC Attn: Security 8 The Green, Suite A Dover, DE 19901 United States security@misecentral.com