Skip to content
All articles
Protocols30 July 2026·7 min read

The outage that comes with a date printed on it

A signing certificate carries its own expiry. Every connection you hold has a scheduled failure attached, and almost nobody has the calendar entry.

Paycux security engineering

Most outages are unforeseeable in principle. This one is not. Every signing certificate you have been given carries a validity period, the end date is right there in the file, and when it passes the connection stops working for everybody in that organisation at once.

It is the only failure in an identity integration you can put in a diary years ahead, which makes it faintly embarrassing that it remains one of the most common causes of a sign-in incident. The reason is organisational: the certificate was uploaded during onboarding by somebody who has since changed jobs, and nothing in either system was watching the date.

What the boundary actually looks like

There is no gradual degradation. Assertions that verified perfectly at one moment fail at the next, for every user of that connection, with an error that says the signature could not be validated. Because nothing was deployed, the first hypothesis in the incident channel is always wrong, and time goes into looking at recent changes that had nothing to do with it.

The tell is the blast radius. One organisation, all of its users, no correlation with a release, starting on an exact boundary rather than ramping. If your logs record the certificate fingerprint used to verify each assertion, the answer is one query away instead of forty minutes of hypotheses.

Watch both directions

The certificate you were given is the one everybody thinks about. Where the customer requires signed authentication requests, or encrypts assertions to you, there is a second certificate travelling in the other direction — yours, held in their configuration. Its expiry breaks the same connection from the opposite end, and worse, fixing it requires their administrator to do something rather than you.

Track both in the same place, with the same alerting, and treat your own certificate rollover as a customer-facing change with notice periods attached. A rotation that requires every customer to re-upload metadata within a week is a support event you scheduled for yourself.

  • Store the not-after date as a queryable field, not just inside the certificate blob
  • Alert progressively — a first notice with months to spare, then weeks, then days
  • Notify the customer administrator directly, not only your own team's channel
  • Record the verifying fingerprint on each authentication so incidents resolve in one query
  • Keep the same discipline for the certificate you publish to them

It is the one failure in the whole integration that you can put in a diary years ahead of time.

Do not relax the check

Under incident pressure somebody will suggest ignoring the validity period, because it makes the symptom disappear immediately. It also removes the only mechanism that limits how long a compromised key stays useful, and a temporary flag added at two in the morning has a way of surviving for years without anyone revisiting it.

The correct emergency fix is the same as the correct planned fix: obtain the new certificate and add it. If your connection model can hold more than one trusted certificate at a time, that operation is additive and safe — the old one keeps working until it does not, the new one works immediately, and there is no coordinated moment where both sides have to switch together.

Make replacement something they can do alone

The customer's identity administrator generally knows a rotation is coming before you do, because they scheduled it. If the only way to update your copy is a support ticket with a certificate attached, you have inserted a queue into a process that had a deadline attached, and you will occasionally miss it.

Give them a screen: upload the new certificate or re-fetch the metadata, see both certificates listed with their expiry dates, and confirm before anything changes. Add a test that verifies a real assertion against the new certificate before it is trusted for live traffic. What you want is for this to become a task their team completes on a Tuesday afternoon without ever contacting you.

Everything here, already built

Sign-in, enterprise SSO, directory provisioning, roles and an audit trail behind one API. Start with the quickstart and have a working sign-in this afternoon.

Start selling to enterprise customers

Create an account, point sign-in at Paycux, and get back to the part of the product that is actually yours.