Best practices for API key rotation in accounts payable invoice processing

[margaret_func]

Our accounts payable team processes invoices through third-party automation tools that connect to SAP S/4HANA 1909 via REST APIs. We’re using API keys for authentication, but our security audit flagged that we’ve never rotated these keys since initial implementation 18 months ago.

I’m researching best practices for API key rotation in production environments where we can’t afford downtime. The challenge is that we have multiple vendor systems connecting to our AP APIs - invoice scanning OCR tools, payment processors, and vendor portals. A naive key rotation would break all these integrations simultaneously.

What rotation frequency do you recommend for production API keys? I’ve seen recommendations ranging from 30 days to 6 months. Also interested in strategies for implementing rotation without service disruption - I’m thinking a dual-key approach where we maintain two valid keys during transition periods, but curious if there are better patterns.

API Key Rotation for S/4HANA AP Integrations

Dual-key (overlapping validity) is the right instinct and the standard pattern for zero-downtime rotation. Here’s how to operationalize it across your stack.

---

Rotation Frequency

For production AP integrations handling financial data, 90 days is the practical consensus — short enough to satisfy most security frameworks (PCI-DSS, ISO 27001), long enough to manage rollout across multiple vendor systems without constant churn. 30-day cycles are aggressive and operationally expensive when you have heterogeneous consumers like OCR tools, payment processors, and vendor portals on different release cadences.

---

S/4HANA 1909 Side: Authentication Layer

S/4HANA’s REST APIs (OData v4, SOAP-bridged services) typically authenticate through SAP API Business Hub or directly via SAP Cloud Connector when on-premise. The credential store depends on your deployment:

• SAP BTP / API Management: API keys are managed as application credentials in the developer portal. You can issue multiple active keys per application — this is your dual-key mechanism natively. (Verify the active-key-per-app limit in your version of API Management.)
• On-premise direct (ICM + SICF): API keys usually map to technical communication users in SU01. Dual-key here means maintaining two technical users with identical authorizations during the overlap window, then decommissioning the old one.

Key config path (on-premise):

SICF → Service node → Logon Data tab → User credentials

Communication users should be assigned to communication arrangements — verify via transaction SPRO → SAP S/4HANA → Cross-Application Components → Communication Management.

---

Rotation Pattern (Zero-Downtime)

1. Generate Key B while Key A remains active.
2. Distribute Key B to one integration at a time — start with lowest-risk (vendor portal), end with payment processor.
3. Validate each integration against your AP invoice endpoint (e.g., /sap/opu/odata/sap/API_SUPPLIER_INVOICE_PROCESS_SRV) before moving to the next.
4. Set Key A expiry to T+14 days after last consumer migrates — buffer for rollback.
5. Revoke Key A only after confirming zero traffic in your API gateway access logs.

---

Additional Controls

• Secrets management integration: Push keys into HashiCorp Vault or Azure Key Vault and have vendor systems pull dynamically — eliminates hardcoded keys entirely and reduces rotation friction long-term.
• Per-consumer keys: Issue separate keys per integration (OCR tool, payment processor, vendor portal) rather than a shared key. Blast radius of a compromised key is then scoped to one system.
• SAP Audit Log: Enable SM19/SM20 or SAIS to flag authentication failures during transition windows — catches misconfigured consumers before they cause AP processing backlogs.

18-month-old keys on financial APIs should be treated as compromised for audit purposes regardless of evidence of misuse.

---

This draft is based on general SAP S/4HANA knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.

[helmutpl]

We rotate API keys quarterly for production systems, which balances security with operational overhead. Monthly rotation is theoretically more secure but creates too much coordination burden with external vendors. Six months is too long - if a key is compromised, you’ve potentially had exposure for half a year.

The dual-key strategy is definitely the right approach. We maintain two active keys with overlapping validity periods. When it’s time to rotate, we generate a new key, notify all API consumers, give them two weeks to update their systems, then deprecate the old key. This gives everyone time to update without service disruption.

[coder_ops]

Key rotation frequency should depend on your threat model and compliance requirements. For financial systems like accounts payable, I’d recommend 90-day rotation as a baseline. If you’re subject to PCI DSS or similar regulations, you might need more frequent rotation.

For the dual-key approach, implement it at the API gateway level rather than in SAP S/4HANA itself. Your gateway validates both the current key and the next-generation key during the transition period. This keeps the complexity out of your core ERP system and makes the rotation process more manageable. We use Azure API Management for this and it handles key rotation gracefully.

[dylan_jones]

I’d challenge the premise of using API keys at all for accounts payable integrations. API keys are essentially long-lived passwords - even with rotation, they’re vulnerable to theft and difficult to scope properly. For financial integrations, OAuth2 client credentials flow provides much better security. You get short-lived access tokens, can implement proper scopes limiting what each client can do, and token refresh is automated.

If you’re stuck with API keys due to vendor limitations, implement automated rotation rather than manual processes. Generate new keys programmatically, push them to a secrets management system like Azure Key Vault or HashiCorp Vault, and have your vendors pull keys from there. This eliminates the coordination burden and reduces human error.

[vrodriguez]

From a compliance perspective, key rotation frequency depends on your regulatory requirements. SOX doesn’t explicitly mandate API key rotation, but auditors expect it as part of access control management. We typically see 90-day rotation as the standard that satisfies most auditors without being operationally burdensome.

The critical piece auditors focus on is your rollback procedure. What happens if a key rotation breaks production? You need documented procedures for emergency key restoration and testing protocols to validate integrations before deprecating old keys. Also ensure you’re logging all API access with key identifiers so you can audit which key was used for each transaction.

[j_sap2]

We manage API keys for 15+ vendor integrations in our AP system. Our rotation strategy: 90-day cycle with a 14-day overlap period. Here’s the timeline: Day 1 - generate new key, Day 1-7 - notify vendors and provide new key, Day 7-14 - vendors update their systems, Day 14 - old key expires.

Key monitoring is crucial. We track API calls by key identifier and send alerts if we see the old key being used after day 10. This gives us early warning if a vendor hasn’t updated yet. We’ve also built a vendor key management portal where vendors can retrieve their current and next-generation keys, see expiration dates, and test their integration before the cutover.

[sap_nikolay]

The dual-key strategy is solid, but implement it with proper key versioning. Each key should have metadata: version number, generation date, expiration date, and status (active/deprecated/revoked). Your API validation logic checks both the key value and its status.

For rollback procedures, maintain a key history table. If you need to emergency-revert a rotation, you can reactivate a previous key version without generating a new one. This is critical when a vendor has issues updating to the new key and you need to keep their integration working while they troubleshoot.

Also consider implementing key-specific rate limiting and monitoring. If a key shows unusual usage patterns during the rotation period, it might indicate the key was compromised or a vendor’s integration is malfunctioning.

[jeffrey_arch]

Let me provide a comprehensive framework for API key rotation based on implementing this for multiple enterprise clients with accounts payable integrations.

Key Rotation Frequency Recommendations:

For production financial systems like accounts payable, I recommend 90-day rotation as the baseline. This frequency balances security requirements with operational practicality. Here’s the reasoning:

• 30-day rotation: Too frequent for systems with multiple external vendors. The coordination overhead becomes a significant operational burden, and you risk integration failures from rushed updates.
• 90-day rotation: Sweet spot for most organizations. Satisfies SOX and PCI DSS requirements, provides reasonable security window if keys are compromised, and gives adequate time for coordinated vendor updates.
• 180-day rotation: Too infrequent for financial systems. If a key is compromised, you have potentially six months of exposure before rotation.

Adjust frequency based on specific factors: increase to 60 days if you have compliance requirements like PCI DSS Level 1, decrease to 120 days if you have very stable vendor relationships and limited integration points.

Dual-Key Strategy Implementation:

The dual-key approach is absolutely the right pattern for zero-downtime rotation. Here’s how to implement it properly:

Phase 1 - Key Generation (Day 0): Generate the new key and store it in your secrets management system (Azure Key Vault, AWS Secrets Manager, HashiCorp Vault). The new key is marked as ‘pending’ status and is not yet active for API validation.

Phase 2 - Vendor Notification (Days 1-3): Notify all API consumers via automated emails that include: the new key value, activation date, old key expiration date, and testing instructions. Provide a vendor portal where they can retrieve the new key and test their integration against a sandbox environment before production cutover.

Phase 3 - Overlap Period (Days 4-14): Activate the new key while keeping the old key active. Your API gateway validates requests using either key. This is the critical transition period where vendors update their systems. Monitor API calls by key identifier to track which vendors have successfully migrated.

Phase 4 - Deprecation Warning (Days 12-14): Send reminder notifications to vendors still using the old key. Escalate to phone calls for critical vendors who haven’t migrated by day 12.

Phase 5 - Old Key Expiration (Day 14): Deactivate the old key. Any requests using the old key receive 401 Unauthorized responses with a clear error message indicating key expiration and providing support contact information.

Automated Rotation Architecture:

For true operational efficiency, implement automated key rotation:

1. Secrets Manager Integration: Store all API keys in a centralized secrets management system. Your API gateway retrieves keys from the secrets manager rather than hardcoded configuration.

2. Automated Generation: Schedule automated key generation 14 days before expiration. The system generates the new key, stores it in the secrets manager, and triggers vendor notifications.

3. Self-Service Vendor Portal: Build a portal where vendors can retrieve their current key, view upcoming rotation schedule, get the next-generation key early, and test integrations in sandbox.

4. Monitoring and Alerting: Implement comprehensive monitoring that tracks API usage by key version, alerts when deprecated keys are still in use, and provides dashboards showing rotation status across all vendors.

Rollback Procedures:

Every key rotation plan needs documented rollback procedures:

Emergency Reactivation: If a vendor has critical issues with the new key, you need the ability to emergency-reactivate the old key. Maintain key history with reactivation capability for 30 days post-expiration.

Validation Testing: Before deprecating any key, run automated tests against all critical AP workflows: invoice submission, payment processing, vendor query. Only proceed with deprecation if all tests pass.

Staged Rollout: For high-risk rotations (many vendors, critical system), consider staged rollout. Rotate keys for non-critical vendors first, validate stability, then proceed with critical vendors.

Key Monitoring and Audit Logging:

Implement comprehensive logging for compliance and security:

• Log every API request with key identifier, timestamp, source IP, endpoint accessed, and response code
• Generate weekly reports showing API usage by key version
• Alert on anomalous patterns: sudden usage spikes, access from new IP addresses, repeated authentication failures
• Maintain audit trail of all key generation, activation, and revocation events

Vendor Communication Template:

Effective vendor communication is critical. Your notification should include:

Subject: API Key Rotation - Action Required by [Date]

Your API key for [System] will be rotated on [Date].

Current Key: [first 8 chars]...
New Key: [Available in vendor portal]
Activation Date: [Date]
Old Key Expiration: [Date + 14 days]

Action Required:
1. Retrieve new key from vendor portal: [URL]
2. Update your integration with new key
3. Test in sandbox environment: [URL]
4. Confirm migration by [Date]

Support: [Contact info]

SAP S/4HANA Specific Considerations:

For SAP S/4HANA 1909 specifically, implement key validation at the API gateway layer (SAP API Management or third-party gateway like Apigee) rather than in the ERP system itself. This keeps rotation logic separate from your core financial system and makes the process more maintainable.

Integrate with SAP’s OAuth 2.0 support where possible. For vendors who can support it, migrate from API keys to OAuth2 client credentials flow. This provides better security through short-lived tokens and eliminates the need for manual key rotation.

Migration Path from API Keys:

Long-term, consider migrating away from API keys entirely:

1. Phase 1: Implement dual-key rotation to establish operational discipline
2. Phase 2: Migrate internal integrations to OAuth2
3. Phase 3: Work with vendors to support OAuth2 client credentials
4. Phase 4: Deprecate API keys for all but legacy integrations

This approach provides immediate security improvements through rotation while planning for a more secure long-term architecture.