How to request encryption/MFA/access changes

Customers often need to implement new security requirements—such as MFA for admin access, stronger encryption, key rotation, access restrictions, or retention/logging changes—to meet internal policies or regulatory obligations.

This article explains how to submit a change request so it can be implemented safely, with clear approvals and minimal service interruption.

Common requests we can help with

Examples include:

• Enforce MFA for administrative or portal access
• Upgrade encryption settings (protocols/ciphers) for data transfers
• Rotate certificates/keys (including PGP where applicable)
• Tighten access control (least privilege, new admin/users, remove access)
• Update logging, audit trails, retention requirements
• Provide security documentation to support vendor risk reviews

What to include in your request (required)

To avoid back-and-forth, include:

1. What is changing (plain English)
   • “We need MFA for all admin users”
   • “We must disable legacy ciphers and enforce stronger encryption”
   • “We need quarterly key rotation”
2. Why the change is needed
   • Internal audit finding, policy update, compliance deadline, security incident prevention, etc.
3. Scope
   • Which environment(s): production / test
   • Which integrations/partners/flows are affected
   • Which user roles or teams are in scope
4. Deadline and desired change window
   • Preferred deployment time (include timezone)
   • Any blackout periods
5. Approvals / stakeholders
   • Who must sign off (Security, IT, Operations)
   • Who should receive update communications
6. Technical constraints
   • Partner requirements (supported protocols/ciphers)
   • Any dependencies (firewall rules, whitelisting, certificates provided by you)

Recommended process (what will happen next)

1. Initial review
   • Support confirms feasibility and identifies any risks or partner impacts.
2. Plan + validation
   • We align on the exact settings/controls and agree on a test approach.
   • If needed, we recommend validating changes in a non-production environment first.
3. Implementation
   • Changes are deployed in the agreed window.
   • We verify connectivity and successful transfer behavior post-change.
4. Confirmation + documentation
   • You receive confirmation of what was changed and when.
   • Where applicable, we provide relevant documentation for audit/compliance records.

Tips to avoid disruption

• Involve external partners early if they must change settings on their side.
• Schedule changes during low-volume periods.
• For encryption upgrades, confirm both sides support the required configuration before cutover.
• For key rotation, plan overlap/transition periods if required.