Security and Access checklist
Administration & operations
Protect the NIM service, browser endpoints, identity connections, and recovery path with a reviewable production checklist.
Secure NIM by protecting browser access, sign-in methods, connector identities, certificates, backups, and administrative access. Review each area before production use and after material access changes.
At a glanceDirect link to At a glance
Use this checklist when preparing a NIM environment for production, after a material access change, and during scheduled security reviews. It does not replace your organization’s security policy or connector-specific requirements. Record the owner, date, evidence, and approved exceptions for each applicable item. Test a limited, safe workflow after changes to browser access, authentication, certificates, or connector permissions.
The CISA Cybersecurity Performance Goals provide a voluntary baseline for prioritizing security work. Use them to review the controls around NIM, such as access, vulnerability management, and recovery; completing this checklist alone does not establish conformance with that baseline.
Production security checklistDirect link to Production security checklist
| Area | Confirm | Evidence to retain |
|---|---|---|
| Browser access | HTTPS uses a valid certificate for NIM Studio and every user-facing App, onboarding, or password-reset URL. | Successful HTTPS access from an expected client and the certificate owner and expiry date. |
| Public exposure | Only approved user-facing routes are published externally. NIM Studio and administrative APIs remain on the internal network or VPN. | Reviewed reverse-proxy routes, DNS name, certificate, and network-path approval. |
| Administrator access | The default Administrator password has been replaced and administrative access follows your approved access model. | Named owners and the approved administrative-access process. |
| Sign-in and sessions | SAML, MFA and session settings, and logout behavior match the organization’s access policy. | Successful controlled sign-in and sign-out test for each enabled method. |
| Connector identities | Every connector account, application registration, certificate, consent, or delegated right has only the access needed for its documented operations. | Connector owner, target scope, approved permissions, and a successful connection test. |
| Certificate lifecycle | HTTPS, LDAP, and connector certificates have an owner, renewal plan, and expiration notification. | Certificate inventory, expiration test or notification, and post-renewal connection test. |
| Directory trust | LDAP connections use the appropriate secure configuration and trusted certificate chain. | Successful connection test and reviewed certificate-chain result. |
| Data protection and recovery | Repositories, backups, and snapshots are scheduled and recovery guidance is tested through a controlled process. | Backup owner, retention expectation, protected storage location, and recovery-test record. |
| Audit and response | Job results, auditing queries, and notifications give the operations team a way to investigate significant identity changes or failures. | Sample job result, audit-query output, and tested notification recipient. |
Configure the essentialsDirect link to Configure the essentials
1. Protect browser and external accessDirect link to 1. Protect browser and external access
Configure HTTPS before exposing NIM or any user-facing identity experience. Replace the installer-created self-signed certificate in production with the certificate method approved by your organization. Enable HTTP-to-HTTPS redirection only after expected clients can use HTTPS.
If you publish approved Apps externally, use the external access guide. It uses a reverse proxy for approved public routes; do not expose NIM Studio or the administrative API to the public internet. Administrators should use the internal network or VPN.
Use CISA's Internet Exposure Reduction guidance to review which NIM routes actually require public access. After publication, CISA Cyber Hygiene Services can help eligible organizations identify vulnerabilities and exposed services on their internet-facing infrastructure. Scan the public host with your security team's approval and verify that only intended App routes are reachable.
NIST SP 800-207 explains why network location alone should not grant trust. Keep authentication, authorization, and least-privilege checks in place for approved public Apps and internal administrative access, even when a reverse proxy or VPN controls the route.
2. Protect sign-in and sessionsDirect link to 2. Protect sign-in and sessions
Review Sign-in, branding, and sessions in Configuration → Settings → Preferences. In addition to the login flow and MFA requirement, check these session security options against your access policy:
| Preference | Security review |
|---|---|
| Session timeout for admin | Set the maximum administrator session lifetime in minutes. The documented default is 60 minutes; the allowed range is 5–720 minutes. |
| Session timeout for non administrators | Set the maximum lifetime for other users' sessions. The documented default is 480 minutes; the allowed range is 5–720 minutes. |
| Session timeout when idle | Limit how long an inactive session remains open. Test that users are signed out after the intended idle period. |
| Session warning time (seconds) | Choose how early NIM warns users that their session is expiring. A value of 0 disables the warning. |
| Session ignore SAML notOnOrAfter | Keep this at 0 during normal operation so NIM honors the SAML session expiry. Use 1 only for a reviewed integration requirement. |
Align session timeouts with NIST SP 800-63BDirect link to Align session timeouts with NIST SP 800-63B
NIST SP 800-63B, Session Management distinguishes an overall timeout (time since authentication or reauthentication) from an inactivity timeout (time without user activity). When either expires, the session must end; the user must reauthenticate to continue. Map NIM's Session timeout for admin and Session timeout for non administrators to the overall limit, and Session timeout when idle to the inactivity limit. Choose the limits for the authentication assurance level (AAL) required by your organization's access policy:
| NIST level | Overall reauthentication timeout | Inactivity timeout | NIM settings to review |
|---|---|---|---|
| AAL1 | NIST recommends no more than 30 days. | Optional. | NIM's maximum overall session setting is 720 minutes (12 hours), already shorter than the AAL1 recommendation. Set an idle limit if your policy requires one. |
| AAL2 | NIST recommends no more than 24 hours. | NIST recommends no more than 60 minutes. | NIM's maximum overall setting is 12 hours. Set Session timeout when idle to 60 minutes or less. |
| AAL3 | NIST requires no more than 12 hours. | NIST recommends no more than 15 minutes. | Keep both overall settings at 720 minutes or less and set Session timeout when idle to 15 minutes or less. |
These limits come from the NIST AAL reauthentication requirements. NIST uses SHOULD for the AAL1 and AAL2 overall limits and the AAL2 and AAL3 inactivity limits, but SHALL for the AAL3 overall limit. Session warning time can alert users before expiration; it does not replace either timeout. For SAML sign-in, keep Session ignore SAML notOnOrAfter at 0 and review the identity provider's session policy too: NIST notes that identity-provider and application sessions are independent.
Matching timeout numbers alone does not establish AAL2 or AAL3 conformity. The authentication method, reauthentication behavior, session handling, and other NIST requirements must also meet the selected level. Record the selected limits and test that activity resets only the idle timer, while the overall timeout still requires reauthentication.
Test the resulting sign-in, idle, expiration, warning, and sign-out behavior with controlled administrator and non-administrator accounts. Use SAML or LDAP only when the related identity and directory configuration has been tested with controlled users.
Set the logout redirect only to a destination that is trusted in your access design. Keep NIM’s default Administrator account protected with a strong, organization-managed password and limit access to the people who administer the environment.
3. Manage certificates and connector accessDirect link to 3. Manage certificates and connector access
Use Certificates to track the material NIM uses for HTTPS, connector authentication, and LDAP trust. Assign a renewal owner and notify that owner before expiration. After replacing a certificate, test the affected endpoint or connection before removing the prior certificate.
For connected systems, follow Prepare connector permissions and the selected integration’s own connection guide. Do not increase permissions across a tenant or directory merely to resolve an initial failure; identify the failed operation and its required scope first.
4. Protect changes, data, and recoveryDirect link to 4. Protect changes, data, and recovery
Create configuration repositories, schedule backups, and use snapshots before significant changes. Store backup exports in an access-controlled location outside the NIM server. Test recovery with a controlled process before an incident requires it.
Use auditing queries, job results, and notifications to make identity changes and failures reviewable.
Review high-risk settings before enablingDirect link to Review high-risk settings before enabling
- Keep Script debugging disabled in production except during an approved, time-bounded troubleshooting session; disable it again when the session ends.
- Do not bypass TLS certificate validation as a permanent fix. Correct the certificate trust chain or network configuration instead.
- Enable HSTS only after HTTPS is fully working for the intended host. Include subdomains or preload only after reviewing the consequences for every affected domain.
- Keep the MCP API endpoint disabled unless an approved client needs it. If it is enabled, review authentication, least-privilege access, whether customer data access is necessary, and the change approval.
- Review framing and browser security-header settings with the team responsible for reverse proxies and embedded content before changing them.
Validate and reviewDirect link to Validate and review
After a security-related change, test a controlled sign-in, the relevant HTTPS or public URL, one connector connection, and one limited target operation. Review the corresponding job result and confirm that operational notifications reach the intended owner.
Review this checklist on a regular cadence and whenever you change public access, an identity provider, connector permissions, certificates, or the NIM service environment. For technical failures during a tested workflow, use Monitor and Troubleshoot.