Release notes for auth changes
How to communicate changes that affect users
When you ship auth changes (new MFA, password policy, login UX), users need to know. Done well, builds trust. Done poorly, support floods.
What needs release notes
- New auth methods (passkey, social provider).
- Policy changes (MFA now required for X).
- UI changes affecting flow.
- Email template updates.
- Security improvements (password breach checks).
Bug fixes typically: silent.
Template
# Release X.Y.Z, 2026-05-13
## Summary
- WebAuthn / passkey support is now live.
- Improved password strength meter.
- Bug fixes.
## New
### Passkey support
You can now sign in with a passkey (Touch ID, Face ID, Windows Hello).
Settings → Security → Set up passkey.
[Learn more](/docs/cookbook/auth-flows/feature-detect-passkeys)
## Changed
### Password strength meter
The password strength meter now uses zxcvbn for more accurate feedback.
Common passwords are detected and disallowed.
## Security
- Sessions are now revoked when password changes.
- Two-factor codes are checked against a stricter time window.
## Migration
No action needed. Existing users:
- Will see passkey option in next sign-in.
- Should consider enrolling for better security.
## Deprecation
None.Sections
Summary
1-2 sentences. What's the headline?
New
User-facing additions. Include link to docs.
Changed
Existing behavior modified. Note what changed AND impact on users.
Security
Improvements worth highlighting separately. Builds trust.
Migration
If users need to do anything, say so clearly.
Deprecation
Coming changes. Give time for action.
Tone
User-facing language. Not developer-speak.
GOOD: "You can now sign in with a passkey."
BAD: "Added WebAuthn assertion handling via /self-service/login/code flow."Where to publish
Multiple channels:
/changelogpage in your app.- In-app banner ("What's new").
- Email to active users.
- Status page.
- Blog post (for major).
In-app banner
{user.last_seen_release < currentRelease && (
<Banner intent="info">
What's new: passkey support is now available. <Link href="/changelog">See details</Link>
</Banner>
)}Dismiss after viewing.
Per-feature opt-in
Sometimes notes invite users to try:
### Try passkey sign-in
Settings → Security → Set up passkey
Save your passkey now to make signing in faster and more secure.CTA in release notes.
Don't surprise users
For impactful changes, give warning:
30 days before:
"Starting June 1, all admin accounts require 2FA. Enroll now."
7 days before:
"Reminder: 2FA enrollment ends June 1."
Day 0:
"2FA is now required for admin accounts."Pre-announce. Avoid lockouts.
Major version
For breaking changes (rare in auth):
# Major Release v2.0, 2026-12-01
## What's changed
- Token format is now JWT (was opaque).
- Issuer URL changed: https://auth.your-domain.com.
## Action required
Update your apps:
1. Use new issuer URL.
2. Update JWKS endpoint.
3. Test before December 1.
[Migration guide](/docs/migration/v1-to-v2)Bold. Hard deadlines. Step-by-step.
Versioning
Semantic:
- 1.0.0 → 1.0.1: patch (bug fix).
- 1.0.1 → 1.1.0: minor (new feature, backward compat).
- 1.1.0 → 2.0.0: major (breaking).
User-facing notes: focus on minor + major. Patches usually silent.
Per-tenant filtering
In white-label, customize per-tenant:
const notesForTenant = await loadNotes(tenant.id);Some changes are global; some only affect specific tenants.
Archive
Past notes accessible:
/changelog/2026-05-13/changelog/2026-04-22
Searchable. Linkable. Customers can verify "when did X change?"
Markdown source
Notes in markdown files:
changelogs/
├── 2026-05-13.md
├── 2026-04-22.md
└── ...Versioned. Reviewable in PRs.
# Each PR with user-impact: add to changelog
- [ ] Changelog entry addedCode review checklist.
RSS feed
For developers / integrators:
<?xml version="1.0"?>
<rss version="2.0">
<channel>
<title>Olympus changelog</title>
<item>
<title>Passkey support</title>
<pubDate>Tue, 13 May 2026 ...</pubDate>
<link>https://your-domain.com/changelog/2026-05-13</link>
<description>...</description>
</item>
</channel>
</rss>Subscribe to stay updated.
Don't pad
Quiet weeks = quiet changelog. Don't invent.
If you do release infrastructure / internal changes (no user impact), separate:
# Engineering notes (no user-impact)
- Migrated to Bun 1.2.
- Refactored audit logger.
- Updated Postgres to 16.4.Different audience.