Shipped: FusionAuth Quarterly Product Update

Blair Ewalt — 00:03–01:46

Thank you for joining today. We're just going to give people a minute here to trickle in, and then we'll kick it off.

Cool. So we can get started here. Hey, everyone. Thanks for joining us for FusionAuth's quarterly product update for Q1 2026. I'm Blair. I'll be your host today.

We've got a really packed session. Mark Robustelli, one of our best developer relations engineers, is going to walk you through everything that shipped recently — from phone numbers as first-class identity, to preverified identities, universal applications, tenant manager, MFA requirement Lambdas, DPoP token binding, and a look at what's just landed in 1.64. If you have any questions along the way, drop them in the chat, and we'll get to as many as we can at the end.

So with that, Mark, I'll hand the stage over to you — take it away.

Mark Robustelli — 01:46–24:29

Thanks for the amazing introduction there, Blair. Welcome, everybody.

Normally it's just the quarterly product update, but since this is our first one, let me go back a little further. I think it's important to start off by talking about why updates matter. Identity is evolving. A few years ago, it used to be: throw in six characters, a couple special ones, and you're good to go. Since then, password requirements and complexity have evolved — we have things like MFA, passwordless login. Identity is constantly evolving, and one of the nice things about using a product like FusionAuth is it allows you to evolve with it. It gives you the flexibility to stay on top of this stuff without having to rebuild your auth, so you can focus on the things that are important to your application.

I want to talk a little bit about expectations. This is a product update, so if you've never seen FusionAuth before, please stick around — we'll tell you about the cool things. But when we're done, go ahead and head over to the FusionAuth website to check it out and learn more. Or if you're a developer, I always recommend checking out our quick starts to get hands-on pretty quickly.

The release notes are out and available for all our releases. Our latest release is 1.64. You can go to the website anytime and check those out.

So let's talk about what's new — ish. Like I said, we're going back just a little bit further than just this quarter, but we've got some amazing features and updates we want to make sure everyone is aware of.

The first thing I'd like to talk about is preverified identities. I think this is a good one to start with because it's one thing to read about a feature in the release notes, and it's another to see it in action. Why is preverified identities an important feature? It allows you to verify the identity before the username goes into your database. This helps you keep a clean database, prevent fake accounts or zombie accounts, and prevent identity squatting. I think we've all been there — you go to a new service or website, sign up, and it says, "Oh, hey. You already signed up." Well, that wasn't me. This helps prevent that.

What I'm going to do here is jump over to our demo environment. I've got my FusionAuth admin set up on this side. I've got my ChangeBank application here — that's the application we use for our quick starts — and it allows me to log in and show you some of these features. For the purpose of this first demo, I want you to see we've only got a couple of users registered here. Three. So if I look at my demo app, you can see I have the registration verification set up for the application.

I'll click over here for users. Normally, when I go to create an account, we'll call in "test no pre verification," type in a password, and I register. As soon as I hit that register, you'll see my "test no pre" example user is already in the database — but they haven't completed verification. So if they don't do that, that account is now abandoned. If it wasn't their email address, someone else who logs in with that email address will look like they're already registered. I'm going to go ahead and close out that application — that's how it works without preverification.

To implement preverification, I have to do a little setup. One of the things I need to do is create a custom form. I already have one here called "email preverification." The first thing you can notice is that I'm only asking for the user's email — nothing else. The next step will be to ask for the email verification, and then the other fields. In this case it happens to be password, but you can add username, first name, last name, any data you want to collect about the user. That's my email preverification form.

Now I have to apply that form to the application. I'll go back into my demo here, turn off the application verification, go down to self-service registration, click advanced, and select my email preverification form. I'll save that, bounce back over to the users, and go to log in. This time I'll create an account — I'll call him "test pre," hopefully with the right email address. When I click next and then click over to the user to refresh, you can see "test pre" is not there yet. I'll go check my email, get the validation code, click next, enter my password. Now that the user has been verified and registered, I click on users and see that "test pre" is now registered. That's a pretty good demonstration of the value of this feature.

We do have a really well-written blog post about preverified identities. I recommend you check that out — it'll give you all the steps to get started.

Next, I want to talk about phone number identity. This is really important because there is no longer an email requirement for identities. This can be useful for things like mobile-first applications or markets where phone adoption exceeds email usage. The other nice thing is that phone numbers are generally tied to real people — they're a little bit tougher to fake, and they can help limit bots and fake accounts.

Let me show you how to implement that. I'll bounce back over to our demo environment. I'll go back to my applications, edit the application, set it back to basic, and then change the login type to phone. Once I've done that, I can come back over to my quick start application, go to login, and create a new account. You'll see it's now asking for a phone number. I'll put in my phone number, enter my password, and when I want to register, it asks me for my code. I pull the code, and just like that, I'm logged in. If I come back over to users, you'll see the new user I just added with just the phone number — no email address. The implementation is pretty straightforward. You can also use the preverification flow with the phone number as well.

So — phone number identity, pretty straightforward, pretty useful. Next, I'm going to talk about tenant manager. If you're in a situation where you're tired of managing your customers' users — resetting their passwords, updating information about them — this is for you. It's a tenant-level application where you can give users specific access to do things like create users for the tenant, lock or unlock them, enforce password resets, and update some information.

The URL for tenant manager within FusionAuth is simply your FusionAuth URL followed by /tenant-manager and the tenant ID. I'll log in as a tenant admin — I'm in my AWS agent tenant, and I only have one user, which is me. From here, I can do something like create a user, add a name, and save. I'll click on users, and you can see that user exists. Because I'm logged in as the tenant admin, I only see those users. If I bounce back over to my admin UI view, I can click on users and see everybody — and confirm the new user has been added. The tenant admin can only see and adjust users for those they have access to.

That's our tenant manager. Next feature: universal applications. These are really useful. In previous versions of FusionAuth, if you had an application you wanted to run across multiple tenants, you'd have to set up the OAuth config, the JWKS configuration, multifactor auth, registration settings, all of that — and then copy the application to each tenant. With universal applications, you just have to create one. As you can imagine, if you have many tenants and you change the config in one but not another, you get drift. This solves that problem.

The neat thing is you've actually already seen an example of a universal application — the tenant manager application ships with FusionAuth, and it's really easy to see it's set as a universal application through a toggle. If I look at my other applications, they all belong to a specific tenant. When you're creating an application, it's very straightforward: instead of selecting a tenant, you just select universal, the tenant field goes away, and that's it.

So those are two new features to help with tenant management. The next feature I'm going to talk about is MFA requirement Lambdas. Even people familiar with FusionAuth may not be familiar with Lambdas, so let me describe what they are. They allow you to write some code that gets executed on certain events within FusionAuth. If you're not familiar with Lambdas, I highly recommend checking out our documentation — they're a super powerful customization feature.

So why do you need an MFA requirement Lambda, and what does it do? Anytime FusionAuth looks to determine whether it should ask a user for multifactor authentication, before this was handled entirely internally. Now we give you a chance to plug into that process and say, "Wait — this user is in a certain state, and I want to make sure they supply their MFA." To give you a little example, let me bounce back over to our demo.

For this demo: I'm a FusionAuth admin, and there's a user named Richard who's upset me. I want to make his life a little more difficult by requiring him to use MFA every time he logs in. So I'll create a Lambda — I'll call it "Hey, I know Richard's MFA." The logic is simple: anytime anybody logs in with Richard's email address, I'm going to require them to log in with MFA. Then I'll go into my application, click on multifactor. I don't have multifactor set up for the application in general, but I'll choose this Lambda. Once I've done that, I'll log out of the application and log back in as Richard — and you can see it's now offering the authentication challenge. I pull the factor code, and Richard logs in. To prove it's just Richard, I'll log in with "test pre," the user we created earlier. With the right credentials, test pre logs in with no problem — no MFA required.

Obviously, this is a very simplistic example. In the real world, you'd want to do something more advanced — for example, if you have location services, you could say anyone logging in outside of the United States needs MFA. Or if you have an application that monitors user status on the dark web, looking for compromised accounts, you could have the Lambda call that and say, "This user is on the list — require MFA." Those are more advanced use cases.

The next security feature I'm going to talk about is DPoP. And no, it's not the Dutch version of K-pop. DPoP stands for Demonstrating Proof of Possession. This is a little more technical, so I'll give you links afterward if you want to dive deeper. For a quick overview: it's an OAuth 2.0 extension that binds a token to a client key. Why does this matter? Assuming everyone on the broadcast is aware of what a JWT is — a JSON Web Token, used for authentication and authorization — one of the downsides of a JWT is that anyone who has it can submit it and act on behalf of the user. That's why we're so adamant about not storing JWTs where anyone can access them. DPoP helps with this by adding the requirement of a client key that's tied to the token.

A little bit of under-the-hood detail: FusionAuth does support DPoP now. It acts as an authorization server — it'll extract the DPoP proof key and signature, verify the signature, calculate a thumbprint, bind the tokens to the thumbprint via a cnf claim, and then return the token type of DPoP. The nice thing is that there's no configuration needed on FusionAuth's side. FusionAuth responds to the token request with the DPoP header if it contains the proof, as long as the requesting client initializes the DPoP flow.

One caveat: when you use DPoP, the API receiving the access token will need some additional steps to validate that the access token was sent by the correct client. SDK support for this isn't available yet, but it is coming. If you need more info, there's a link to our documentation.

I know what you're thinking: "Mark, holy cow, that's a lot of stuff." But wait — there's more. Earlier I mentioned our release notes, and I thought this would be a good time to show some of the work the developer success team here at FusionAuth has put into them. You can now filter our release notes by category. To give you an idea of what some of those categories are, I pulled a few from the latest release.

One category is new features. One thing we released is Lambda secrets — when we were talking about the MFA requirement Lambda, I mentioned you might want to call an API that requires a key or secret. We now have a way for you to securely store those secrets in FusionAuth so they don't have to be in the Lambda code itself.

We also have enhancements — things that may not rise to the level of new features but are valuable. For example, in 1.64, one of the things we released are codes for passwordless email logins. You don't just have to use magic links anymore. We also have smaller things like custom page titles and improvements to our simple themes editor.

And with each release, we have fixes. Some are bigger, some are smaller — one example from the 1.64 release was the standardization of inconsistent title casing in the admin UI. If you want to see every feature, enhancement, and fix, go check out our release notes. And with each release, we also publish a blog post that highlights the updates or new features you're most likely to find valuable.

I know we covered a lot today, so let me recap. For identity: preverified identities, phone number identity with multi-tenant support. For tenant management: universal applications, tenant manager. For security: MFA requirement Lambdas, DPoP, Lambda secrets, and more. I know I threw a ton at you very quickly. I hope the demos were useful and showed you what these features can do. With that, Blair, I think we can go ahead and jump into Q&A if there are any questions.

Blair Ewalt — 24:29–24:52

Sounds great. Thanks, Mark, for walking through all that — really seems like a jam-packed quarter-ish of features, and a lot shipped this quarter. We have had a few questions come in. For MFA requirement Lambdas, what kind of context do you get access to? Can you see the user's location or how they authenticated?

Mark Robustelli — 24:52–26:24

Yeah, really interesting question. I have some of the documentation up here, and you can see within the Lambda itself you will have access to a couple of objects — the user object, the registration, and the context. So if you do have location verification set up, you can access it. Let me jump back over to our admin UI.

Apologies. If you come back into Customizations and go into Lambdas and look at the MFA Lambda, you can see within the function the user, the registration, and the context objects. Any information contained in those objects is available to you. And with things like the HTTP connector inside the Lambda — which allows you to call outside of FusionAuth — you can access anything you have an API for. Does that make sense?

Blair Ewalt — 26:24–26:39

Yeah, that's great. One other question — and please feel free to drop any more questions you may have and we'll get to them. Are all of these features available in the community edition?

Mark Robustelli — 26:39–27:35

The short answer is no. We have a few different editions of FusionAuth, and the community edition is one you can run locally for free, but not all of these features are available. Some are — phone number identity is available, for example — but things like preverification are not, because that requires a customized form, which is a paid feature. If you're interested in which features are available with which plan, our pricing page has a really good comparison of the different editions and their features. And as always, if a feature isn't listed on that page, feel free to reach out to our sales team and they'll get you the information you need.

Blair Ewalt — 27:35–28:25

Sounds good. We'll leave it open for another few seconds and see if any more questions come in. Overall, thank you for everything, Mark. If you want to dig deeper into anything you saw today, feel free to check out fusionauth.io/docs/release-notes for the full changelog, and the blog post linked in the slides for feature-specific walkthroughs. We will be sending this out as on-demand content as well, so if you have questions, feel free to reach out. We'll be running these quarterly, so keep an eye out for the next one. Thanks for joining, everyone — really appreciate your time.

Mark Robustelli — 28:25–29:00

Yeah, real quick, Blair — there didn't seem to be too many more questions coming in, so that means one of two things. Either I did the best job in the world and answered every question and showed everyone exactly what they needed — which is probably not the case — or there's a lot of information here that you're processing. This is the first version of this we've done, and I'd really appreciate some feedback from those of you watching. Were the demos in-depth enough for you? Are there other things you'd like to see? I'd love to hear your feedback on how we can make this better.

Blair Ewalt — 29:00–29:06

Perfect. Thanks, Mark, and thank you, everybody.