.png&w=3840&q=75)
Part 1: Authentication is Solved, but Management Isn't |Why Custom-Built User Logic is Your New Technical Debt
目次
Introduction
Aso: Hello, I’m Aso from TC3’s Corporate department. Previously, I spoke with Mr. Sudo, TC3’s CEO and Product Owner of "Tactna," about the differences between IDaaS solutions like Auth0 or Cognito and Tactna. To dig deeper into that topic, I’ve organized a three-person roundtable discussion today, welcoming Mr. Sanada, the Head of Development for Tactna.
I originally planned to discuss the risks of building authentication and user management functions via custom development (whether in-house or outsourced)...
Aso: Thank you both for gathering today. The theme of this roundtable is "Why Custom-Built Authentication Functions Become 'Technical Debt'." I’d like to discuss the risks of building from scratch—whether internally or through vendors—from the perspective of "Security Risks" and the "Post-CIAM" concept Mr. Sudo mentioned on LinkedIn...
Sudo: Aso-san, sorry to interrupt. I hate to flip the table right at the start, but honestly, I feel like that theme itself is already out of sync with the current market environment.
Aso: Out of sync? How so?
Sudo: The debate over whether to build "Authentication" itself is, in a sense, already over. With authentication technologies becoming more sophisticated every day—like passkeys and biometrics—almost no company tries to build this from scratch anymore. The industry standard is already to leave that to IDaaS (Identity as a Service) providers like Auth0 or Amazon Cognito.
Sanada: I agree. As an engineer on the ground, I feel the same way. If you use IDaaS, you can get a robust "login screen" immediately. However, the biggest trap is thinking, "We implemented IDaaS, so our development around authentication is finished."
"Authentication" is Solved, but "Management" Remains
Aso: A trap? If IDaaS is implemented, what problems remain?
Sudo: What IDaaS excels at is strictly "identifying the user (Authentication)." It safely confirms, "Is this access really by the person they claim to be?" That’s it. But for companies operating Web services—especially B2B SaaS (which includes team usage, not just closed corporate systems)—the truly necessary function is "how to manage and mobilize those identified users." We call this "User Lifecycle Management."
Aso: User Lifecycle Management...?
Sudo: Exactly. A user is Created, Assigned specific permissions for a specific app, Updated when their attributes change due to promotion or transfer, and finally, their permissions are revoked and the user is Deleted upon resignation. It refers to this entire flow.
Particularly in B to B, you always get requests like, "Corporate administrators want to invite their own subordinates," or "We want resigning employees to delete their own accounts." These management functions are actually not sufficiently provided by the IDaaS main body itself.
Examples of Actions and Purposes in User Lifecycle Management
Action | Purpose/Trigger |
Create | A user is created. |
Assign | Assigning which applications can be used with what permissions. |
Update | Changing attributes in accordance with team transfers or promotions. |
Revoke | Revoking permissions due to project completion or transfers. |
Delete | Completely removing the account from all systems upon resignation. |
Sanada: That's right. So, what happens on the ground? Engineers end up building a "Management Screen" from scratch behind the scenes every single time. They build a management screen for App A, and when App B is built, they make another one...
As a result, while Authentication (Login) is standardized via IDaaS, the "Management Functions" and "Permission Logic" behind it are continuously Rebuilt for every service. This is the true nature of the "invisible debt" that keeps burning through development resources.
Aso: I see. So the debt isn't "building authentication," but "rebuilding the management functions that sit on top of authentication every time."
Sudo: Exactly. We call this area "Post-CIAM." We believe the "Business Logic and Management Layer" that sits on top of the "Security Infrastructure" (IDaaS) will be the main battleground moving forward. Tactna is the component designed to fill exactly that gap.

It’s Not "Maintenance." It’s a Game of Cat-and-Mouse with "Functional Expansion"
Aso: That makes sense. Rebuilding it every time is wasteful, and the "maintenance" after it's built must be tough too.
Sudo: Hmm, the nuance there is slightly different too. People often call it maintenance, but the reality isn't just maintenance; it’s functional and non-functional expansion to adapt to ever-changing societal needs. That is the biggest challenge.
Aso: Functional expansion?
Sudo: Yes. When you build it yourself (In-house Build), you inevitably optimize it for "the requirements of the current app" to keep costs down. But businesses grow. New apps are added, billing models change, or eventually, AI agents might enter as users...
Every time these new requirements arise, a proprietary management platform requires patchwork development to add features. This means you aren't fixing what’s broken (maintenance); you are forever incurring development hours to add what’s missing (functional expansion).
Sanada: That is exactly it. Even if it starts simple, as apps increase, requirements become more complex: "We want to change permissions for members per app even within the same team," "We want to invite members," "We want IdP federation per team." You end up redoing the database design every time.
This is the true identity of the "cat-and-mouse game" that exhausts engineers.
Because Tactna is built as a "Platform" with extensibility as a prerequisite, we can handle new apps or new user types (like AI) simply via configuration. The difference in perspective—"Building for the current app" vs. "Buying a platform for future extensibility"—is massive. This holds true even though the speed to initial release is comparable in both scenarios.
The Second Security Risk Hiding in Self-Made "Management Screens"
Aso: The story about the "cost of continuous expansion" really clicked. But I also want to ask about "Security," which was our original theme. If it's just a management screen, isn't it secure enough to build in-house as long as we use IDaaS?
Sudo: That is another blind spot. Actually, there are two major layers to security.
- Security of User Identification (Authentication): This is solved by delegating to IDaaS.
- Security of Infrastructure & Application: This problem remains.
Sanada: In short, after safely identifying the user, the application side must remain secure while utilizing that user data.
Threats in the world evolve daily. Every time a new vulnerability is found, you must update libraries and apply patches to your self-developed system. No matter how robust the IDaaS is, if there is a hole in the application above it, information will leak from there.
Sudo: Right. "Building something that works" and "Maintaining a secure state" are dimensions apart. With scratch development (Build), security obsolescence begins the moment you build it. Trying to defend perfectly against the latest attack trends using only in-house (or vendor) engineering resources is realistically very costly and difficult.
Sanada: On the other hand, the merit of adopting a SaaS like Tactna (Buy) lies here. As a SaaS vendor, we constantly perform infrastructure security updates and monitoring. Tactna has obtained ISO 27001 (ISMS) and 27017 certifications and undergoes strict reviews by AWS (FTR), placing great importance on the "black box" portion of the service.
Sudo: "Authentication" is protected by IDaaS, and the user management on top of it is protected by Tactna's robustness.
Sanada: Being able to provide that peace of mind is the decisive difference compared to scratch development. Of course, the management of unique functions for the specific application beyond that must be left to each developer, but many vulnerabilities lurk in this "black box" between authentication and the application.
The Impact: Initial Cost Reduced to 1/3, Duration Halved
Sudo: From a cost perspective, the impact is also significant. In a case study with a client, the development of a common authentication/management platform—originally estimated at nearly 60 million JPY via scratch development—is expected to be contained to about 20 million JPY by combining Tactna and Auth0.
Sanada: Not only does the initial cost drop to one-third, but the time to service launch is also shortened by about half. For Series B+ startups or large enterprises launching multiple services through DX initiatives, this speed is vital. If you use Tactna, you possess a data structure capable of handling "Multi-App / Multi-Tenant" scenarios from the start, so when apps increase in the future, you have leverage and can adapt smoothly.
Sudo: Many companies build with a simple data model thinking, "This is fine for now," only to change strategies later—trying to sell to B2B or adding multiple apps—and ending up having to completely rebuild the system.
A Perspective on the Future: "ID" in the Age of AI Agents
Sudo: If we look further into the future, "Users" won't just be humans anymore. We are already entering an era where "AI Agents" will have a single ID and access various services, right?
Sanada: Exactly. Humans, AI, Edge Devices... in a world where diverse subjects interact in complex ways, correctly managing the lifecycle of each is no longer at a level that can be covered by in-house development. Tactna possesses a model that abstracts and manages not just humans but also AI agents as "Subjects." We currently say "User Lifecycle Management," but "Subject Lifecycle Management" feels more accurate.
Sudo: I agree. By putting IDs into the "organized box" that is Tactna now, companies can smoothly adapt their systems when full-scale AI utilization begins in the future.
Don't "Build Authentication." Instead, "Buy a User (Subject) Structure that can withstand future business changes." This is the biggest reason to choose Tactna right now.
Editor’s Note:
Through this roundtable, it became clear that while "building authentication functions yourself is out of the question, building a customer management platform (an IDaaS wrapper) yourself is also heavy lifting that does not lead to differentiation for most companies."
This allows development resources to focus on providing value to customers, rather than rebuilding customer management platforms. And it ensures you acquire an ID infrastructure that won't collapse in the coming AI Agent era.
For CTOs and business division leaders who are considering IDaaS, or who have already implemented it but are struggling with the development of management functions: please consider Tactna, a Post-CIAM solution that proactively solves the challenges coming "After Authentication."
.png&w=3840&q=75)
