IT Security at Time Cockpit: What Current AI Models Mean for SaaS Services

Apr 21, 2026 by Alexander Huber

Why we are writing about security now

Time tracking data is not a side issue. It is an important and sensitive data foundation: who worked when, for how long, on which project, which hourly rates apply, how teams are utilized, and which services can be documented for customers or funding bodies. This data must be handled with appropriate care.

We take this responsibility seriously and consistently work to meet high standards. For us, the key point is not one particular model, but something more fundamental: when vulnerabilities can be found and exploited faster, the value of clean architecture, strong identities, and reliable operational processes increases. Claude Mythos Preview, which received a lot of attention in April 2026, is therefore mainly an occasion for us to explain transparently how we operate time cockpit, which security precautions we take, and why moving to Microsoft Entra makes sense for many organizations.

What current AI models change for cybersecurity

The specific trigger for this article is Claude Mythos Preview. From our perspective, however, the product name matters less than the direction of travel: current frontier models are becoming significantly stronger at coding, reasoning, and cybersecurity tasks. Anthropic describes Mythos Preview as so capable that the model was not released broadly, but made available only to a limited group of partners as part of “Project Glasswing”. The aim is to help secure critical software faster before such capabilities can be widely misused. (Anthropic System Cards)

What matters here is not only that a model can find individual vulnerabilities. The critical point is the path from analysis to a practically usable exploit. Modern models are getting better at chaining multiple steps of an attack: analyzing, forming hypotheses, testing, adapting, developing exploits, and moving on. This is exactly what makes the development so relevant for security teams, because it lowers the barriers for very different attacker groups, from less experienced attackers to criminal groups and state actors.

The UK’s AI Security Institute (AISI) concludes in its own evaluation that Mythos Preview shows a clear leap over earlier models in multi-step attack simulations. At the same time, AISI frames this soberly: such models already appear capable of autonomously attacking small, poorly protected corporate networks in controlled tests. This is not a “magic hacking button”, but it is a clear signal: time, cost, and entry barriers for finding and exploiting vulnerabilities continue to fall. For SaaS providers, that does not mean panic. It means more discipline in architecture, identities, and operations.

Three terms briefly explained: A zero-day is a vulnerability for which no patch is available yet. A sandbox is an isolated test environment. An exploit is a program or code that deliberately takes advantage of a vulnerability.

Why authorities and security teams are paying attention

The concern around such models is not only about individual demo scenarios, but about the potential for scaling. If security research is accelerated, defenders benefit at first, too. At the same time, however, the risk increases that research turns into practically usable exploits faster and that weakly protected systems can be attacked more quickly and systematically. That is exactly why security fundamentals that used to be “important” become a much harder quality benchmark in an AI-supported threat landscape.

What this means for SaaS providers like us

For SaaS providers, the right response in our view is not alarmism, but discipline. What matters is not individual marketing buzzwords, but an operating model that keeps typical error surfaces small. From our perspective, that includes above all a combination of:

the smallest possible attack surface
clear and restrictive access rights
automated, traceable deployments
solid separation of tenants and identities
continuous monitoring and improvement

From this perspective, we want to show how we operate time cockpit, with particular attention to attack surface, tenant separation, identities, and traceable change.

How we operate time cockpit

Microsoft Azure only, PaaS only

All services we operate for time cockpit run in Microsoft Azure. We consistently rely on Platform as a Service (PaaS). We do not operate virtual machines, SQL Managed Instances, or our own on-premises server infrastructure.

The advantage is clear: Microsoft patches and operates the underlying platform components and takes care of physical security, baseline hardening, and platform availability. For us, this is not primarily a convenience argument, but a deliberate reduction of infrastructure that we would otherwise have to harden ourselves. This significantly reduces our operational burden and attack surface. At the same time, the shared responsibility model also applies in the cloud: Microsoft is responsible for the platform; we are responsible for our application, configuration, identities, permissions, and processes.

Microsoft Azure provides a broad range of compliance offerings and certifications, including established standards such as ISO 27001 and various SOC reports. This foundation is an essential building block for us.

From our perspective, PaaS is not a marketing term, but a security and operations principle: less self-operated infrastructure, less patching effort at operating system level, fewer manual interventions, and therefore fewer opportunities for avoidable mistakes.

Deployments only through CI/CD, infrastructure as code

We deploy time cockpit exclusively through CI/CD pipelines in Azure DevOps. Manual deployments to production systems are not our operating model. In addition, we manage our infrastructure consistently as Infrastructure as Code (IaC).

Why is this relevant for security?

Changes are versioned and traceable.
Infrastructure is created reproducibly instead of “by clicking”.
Reviews become easier because configurations are visible in code.
Rollbacks and controlled changes become more predictable.
Manual configuration errors are reduced.

At a time when vulnerabilities are found faster, not only speed matters, but also consistency. IaC helps us implement security not only as documentation, but as something repeatable while keeping configuration drift small.

Redundancy, routing, and controlled network traffic

Our infrastructure is designed redundantly. This applies to both Azure SQL Database and App Services. Depending on load, we operate between five and fifteen App Service instances.

In front of our services, we use Azure Front Door. This gives us several advantages:

central policies for incoming web traffic
flexible routing and controlled rollouts
better staging, because we can route individual customers or users to specific instances

For outbound connections, our architecture uses a NAT Gateway. This is not “the one big security feature”, but it is a useful building block for controlled network traffic: it provides predictable outbound IP addresses, simplifies allowlisting, and does not allow unsolicited inbound internet connections through this path.

Between App Services and databases, we use Service Endpoints. This keeps traffic on the Azure backbone and allows us to restrict access to defined network ranges. This also reduces the attack surface.

Tenant separation at database level

Separating customer data is especially important to us. In time cockpit, each customer has their own database. Our multi-tenancy is therefore not separated only logically through schemas or table filters, but actually implemented at database level. For us, this is not a technical side note, but one of the most important security decisions in the product design.

In addition, each user has their own connection string and their own database user. When a user is disabled, this happens not only in the application, but also at database level. From our perspective, this separation is a key security advantage.

Protection mechanisms in Azure SQL Database and App Service

Our databases are configured with 35 days of point-in-time restore. This allows us to return to an earlier point in time in case of an error. We also benefit from features that Azure SQL already provides:

The databases are therefore not only backed up, but also regularly checked for security-relevant anomalies and configuration issues.

At Azure App Service level, we use the integrated platform features for TLS, scaling, and monitoring. Data is encrypted both in transit and at rest. In addition, we run nightly database maintenance, especially for statistics and indexes, so performance and stability remain clean during ongoing operations.

We also harden adjacent infrastructure that is relevant for misuse scenarios such as phishing or spoofing. This includes improvements to SPF, DKIM, and DMARC for our mail domains, as well as CAA records in DNS to deliberately limit the set of authorized certificate authorities. Especially in social engineering attacks, these building blocks are not everything, but they are a useful part of a resilient overall concept. (Microsoft Learn on DMARC and anti-spoofing, Microsoft Learn on DNS record types in Azure)

Authentication and access based on “as little as necessary”

For authentication, we rely exclusively on Microsoft Entra. This applies both to time cockpit itself and to our authentication against the Azure environment in which time cockpit is operated.

Although we are a small team, only a tightly restricted group has access to Azure resources. And even there, the rule is: no access without a specific need. By default, our employees do not have access to customer databases.

If elevated access is required in exceptional cases, for example in support, we use Privileged Identity Management (PIM). PIM allows temporary, traceable permission assignment according to the just-in-time principle. Role assignments are logged and can be audited. We deliberately avoid permanent, broad administrator rights.

Security often depends less on the question “Who is allowed in principle?” and more on “Who is allowed for how long, for what purpose, and with what traceability?” That is why we keep privileged access as small and as short as possible.

Device security, DevSecOps, and dependencies

Our own devices are managed through Microsoft Intune. BitLocker and Microsoft Defender are mandatory. We also monitor whether outdated software is installed on devices. Multi-factor authentication is a given for us. Insecure second factors such as SMS or phone calls are disabled. As a fallback, we use hardware tokens.

Organizationally, we hold weekly DevSecOps meetings in which we review components, configurations, and anomalies. When we detect anomalies, we try to react proactively instead of improvising only in incident mode.

We also actively monitor vulnerabilities in npm packages we use. In parallel, we are introducing Renovate and expanding its use. Renovate is a tool that automatically detects available dependency updates and prepares them as pull requests. This makes security updates less likely to be missed.

When we build interfaces, we prefer modern authentication methods. Where this is technically not possible, we at least use clearly restricted Personal Access Tokens (PATs) instead of Basic Auth. In the medium term, wherever technically sensible, Workload Identity Federation is the next logical step for us: away from long-lived secrets and toward trust-based machine identities. (Microsoft Entra Workload Identity Federation)

In addition, we operate external health checks from multiple locations in Europe. This allows us to monitor service availability in front of the App Services and look at availability and anomalies from more than one perspective.

We do not store payment data

An often underestimated security aspect is the deliberate decision not to store sensitive data. We do not store credit card or other payment data. Payment processing is handled by Stripe, a specialized payment service provider. This removes an entire area of sensitive data processing from our responsibility.

What customers can do themselves

Even the best SaaS architecture does not replace clean security processes on the customer side. In our experience, the following measures have proven especially useful:

Use Microsoft Entra if available. Many organizations already have Entra through Microsoft 365. It makes single sign-on, MFA, central user management, and clean offboarding significantly easier to implement. For time cockpit, this is usually the most effective lever in practice. You can also find more information in our enterprise features.
If Entra is not in use: no shared accounts, strong and unique passwords, a password manager, and MFA wherever possible. We consider blanket forced password changes at short intervals only partially helpful; good passwords, good second factors, and quick changes in case of suspicion or personnel changes are more important.
Take offboarding seriously. Regularly check whether former employees, external service providers, or previous project partners really no longer have access.
Review roles and permissions regularly. Over time, permissions often accumulate without anyone actively questioning them.
Name a responsible person. A clear application owner or internal contact helps enormously when users need to be created, disabled, or permissions reviewed.

Many security problems do not arise from spectacular zero-days, but from everyday omissions: orphaned accounts, overly broad permissions, missing MFA, or unclear responsibilities.

Equally important is a point that is often underestimated in technical discussions: social engineering. This means attacks in which systems are not the primary target, but people are manipulated, for example through phishing emails, fake login pages, or well-prepared support calls. We would not describe social engineering as the one biggest attack vector across the board, but clearly as one of the most important. The Verizon 2025 Data Breach Investigations Report shows that the human element plays a role in a large share of the breaches examined. This is precisely why technical measures such as Microsoft Entra, MFA, and clean offboarding only really help when they are complemented by awareness, clear processes, and regular employee training.

Why Microsoft Entra is the most sensible next step for many customers

If you are using time cockpit today without Microsoft Entra, now is a good time to think about switching. From our perspective, this is not an optional extra for many organizations, but the most practical next step to bring identities, MFA, offboarding, and policies together cleanly. For many organizations, this is not a major transformation project, but mainly a well-planned identity change with a lot of practical benefit:

single sign-on with the existing company account
central user management
MFA and policies through your own organization
less manual work for onboarding and offboarding
fewer separate passwords for individual services

We actively support our customers with this and guide the change in a structured way.

For existing customers, we help with the move to Microsoft Entra. If you are interested, please email support@timecockpit.com.

For new customers, we want to make getting started even easier in the future, so that Microsoft Entra does not have to be connected retroactively, but can be prepared better from the very beginning. From our perspective, this is the most sensible target state: set up modern authentication cleanly as early as possible instead of retrofitting it later under time pressure.

For the migration, the login email addresses in time cockpit must match the email addresses stored in Microsoft Entra. We provide a checklist so the migration can be prepared cleanly.

As of today, we do not yet support automated SCIM provisioning and do not process Entra ID webhooks for user lifecycle events. In practice, this means that the user must already exist in time cockpit with a matching email address for the assignment to work. In the medium term, we see exactly this as a useful further development for an even more complete Entra integration.

Conclusion

Claude Mythos Preview is above all a signal that cyber risks continue to accelerate. Vulnerabilities do not disappear faster as a result, but they are found faster and in some scenarios become easier to exploit. That is exactly why architectural discipline, identity management, automation, monitoring, and clear processes are becoming even more important.

The relevant question for SaaS providers is therefore not whether AI replaces classic security fundamentals. It does not. The relevant question is how disciplined architecture, tenant separation, identities, and operational processes really are. For us at time cockpit, this means: as little self-operated infrastructure as possible, as few permanent rights as necessary, and as much automation and traceability as sensible. Security is not a single feature and not a certification logo, but the result of many technical and organizational decisions.

If you have questions about our security measures or would like to discuss moving to Microsoft Entra, please contact us. We are happy to help you make your time cockpit environment more secure and easier to administer.