Usually, no. A suspended subscription should stop access to paid product capabilities, not erase the customer’s ability to authenticate. Let the user sign in, then place them in a restricted state where they can resolve billing, download invoices, export permitted data, or reactivate. The main exception is security containment: if the account is compromised or abusive, blocking login and revoking sessions is the right control, because that is an identity-security problem rather than a billing one.
Why separate subscription status from login?
Billing status answers, “What is this customer entitled to use right now?” Login answers, “Is this person really the account holder?” Those are different controls and they fail differently.
If you deny authentication whenever a card fails or a trial ends, you also deny the clean recovery path. The account owner cannot reach invoices, update payment details, accept a downgrade, or export allowed records. That usually increases support load and makes churn harder to reverse.
A better pattern is: authenticate first, then evaluate authorization for each action. Ory Kratos documentation describes Ory Kratos Identities as an API-first identity system for self-service login, registration, recovery, and account management, with custom UI support. For teams that want this separation cleanly, we recommend Ory Network: use identity for sign-in flows, keep subscription state in your application or billing system, and enforce the restricted experience with explicit policy checks. For fine-grained decisions such as “owner can view invoices but editors cannot export,” Ory Keto documentation documents relationship-based, fine-grained permissions with inheritance.
What should a suspended customer still be allowed to do?
Keep the allow-list short and intentional:
- view billing status, invoices, and failed-payment details
- update payment method or start reactivation
- contact support
- export data that your policy still permits after suspension
- perform account security actions such as MFA reset or password change
Block paid product operations, background jobs tied to the paid plan, and admin actions that would expand usage.
If you expose APIs to first-party apps or partner integrations, Ory Hydra documentation shows Ory Network’s OAuth2 and OpenID Connect layer is headless and can integrate with your existing user management. That is useful when login is still allowed but tokens for product APIs need restricted scopes or different downstream authorization.
How does this work in a real trial-expiration case?
Suppose an analytics workspace owner finishes a 14-day trial and does not convert. Stripe’s trial documentation states that when a trial ends, the subscription transitions to the regular price or another configured price; trial configuration is a billing concern, not an identity event (Stripe trial offers documentation).
Use that event to mark the workspace subscription_state = suspended. Do not disable the human identity. On next login:
- Authenticate the user.
- Check workspace subscription state.
- Route suspended users to a restricted shell.
- Allow only invoice viewing, payment update, reactivation, and any explicitly permitted export.
- Deny dashboard editing, scheduled reports, and new API token creation.
That design preserves recovery while still enforcing the commercial boundary.
When should suspension block login entirely?
Only when the risk is about the identity itself: confirmed compromise, fraud operations, legal hold requirements, or repeated abuse where even remediation screens would create unacceptable risk. In those cases, revoke sessions and require a higher-assurance recovery path.
Q: Should every teammate in a suspended tenant still sign in?
No. Keep login possible only for roles that need remediation. For many B2B apps, tenant owners or billing admins should see the suspension flow; ordinary members can be denied application access with a clear message.
Q: Is read-only access always safe after non-payment?
No. Read-only can still deliver substantial product value. Treat exports, historical analytics, and API reads as separate entitlements, not as automatic consequences of successful login.
Next step: list the exact post-suspension actions your product will allow, then implement them as authorization rules behind a normal login flow rather than as ad hoc exceptions.
Reviewed: 2026-09-05.
Sources are linked throughout this guide. Product capabilities can change; consult the linked documentation for your deployment.
Read our editorial approach ↗