Update: V21.0 supports Lets Encrypt onboard:  Sophos Firewall v21 Early Access Announcement  

FINALLY!!!!!!

Now we need the time server back....

Did you had a chance to look into Central Email, which brings all those features (plus additional features as well)? 

UTM customers nowadays are advised to migrate to CEMA (Central Email) instead of using the Email Protection of the firewall.

Email Protection works pretty well I must admit. But its kind of annoying for my team to find reasons for undelivered mail as it is only visible as a tooltip. The use of rbl is very effective and made reports almost obsolet. 

Glad LE finally made it to SFOS. 

Still missing sophos otp for webserver protection though. :(

You could just say, our MTA implementation is crap - and we don't have plans to fix that -> use the cloud product instead.
or move on to solutions that don't get crippled by their successor products.

Currently, all of my customers, when they get to choose between UTM and CEMA, they would go with CEMA all the way, as it is the full fetched email product, coming from the Sophos Email Appliance, which was always the primary Email product of Sophos. 

Nowadays, as Sophos split up the email subscription into an own subscription, everybody can decide what to do with their email product and you are not locked into a bundle. 

The promos of Sophos also include CEMA and not Email on the Firewall. 

The Email protection of Sophos works as it is - and it does it job of scanning and filtering emails. Bugs are getting addressed and fixed as well.

If a customer has certain requirements, you can always interact with Sophos or the Sophos partner to validate the options like moving to CEMA or interacting with another product. 

The only reason not to have an internal NTP server is if you have no internal devices.

Yes, NTP traffic might seem like just bytes moving in and out, but there are significant concerns with exposing this traffic to the internet. NTP traffic is not encrypted, meaning it’s visible to every node it passes through. This not only adds unnecessary latency and traffic on WAN interfaces and routers but also presents a substantial security risk.

Relying on external NTP servers means your time synchronization is vulnerable to man-in-the-middle attacks. Attackers could intercept and manipulate the time data, potentially causing significant disruptions, especially in environments where precise timing is crucial. This vulnerability could impact time-sensitive applications, mismatching log-times are only the start of problems...

It’s puzzling, to say the least, that a security provider like Sophos would suggest its customers expose their devices to third-party NTP servers for something as fundamental as time synchronization. The fact that Sophos collects telemetry from sophos.pool.ntp.org only highlights the irony...

The real issue here is that Sophos had a very good UTM product - one with great usability and a comprehensive feature set. But you chose to abandon it in favor of a new product that is inferior in many ways. XGS suffers from poor usability and manageability (SUM vs SFM or Central anyone?), and many expected features, like an internal NTP server, are simply missing - or only get added after years and customer complaints, hints why we're in this very forum thread.

And to add insult to injury, your sales team still claims the new product is “better in every way”, "easy to move over" (by manually building a new config/ruleset), or my personal favorite from 2018, “full feature parity by the end of the year.”
Why not just be honest? Admit that you don’t want to implement certain features or that (allegedly) you lack the budget or manpower to do so. Stop tiptoeing around the obvious - just be upfront. 

You could simply say, “Yes, that was a great feature in UTM, but we have no plans to bring it to Cyberoam, Sophos Firewall, XG, XGS. Either expose your NTP traffic to the internet with a NAT rule (which, as a SECURITY PROVIDER, we do not recommend), or implement your own NTP solution.”

If your equipment requires millisecond-accurate time, you likely already have the necessary hardware in place. For everyone else, running a GPS NTP appliance or something like Docker-NTP in a container would at least keep the traffic off the WAN.

Finally, consider the compliance implications. Many regulatory standards and industry best practices recommend or even require internal time synchronization services to maintain accurate logs and prevent tampering. By not providing an internal NTP server, Sophos might be inadvertently pushing customers to adopt practices that could lead to non-compliance, potentially opening them up to fines or penalties.

might be a bit off-topic to continue with MTA in this topic...

but moving to a cloud-based mail security solution when your emails are already in the cloud (e.g., EXO) makes (some) sense. However, relying on a cloud service to filter emails when you intentionally keep your mail servers on-premises to avoid data being on 'someone else's computer' (aka the cloud) is not just ironic—it's counterproductive and undermines the very reason for keeping things in-house. I'll keep the discussion about the Central Mail Product off this Thread. 

You cannot compare a UTM product, which started in 2002 with a product, which started its root in a GDPR time. 

Implementing a NTP Server in a firewall nowadays has more to it than only installing a NTP service to a linux system. You need to harden the device - make sure no one can exploit it and escape to other sub systems etc. 
No one says, you have to redirect the time sync to an external service. You can install your own NTP service in your network, which is based on the standards and compliance you have. UTM never fulfill the regulations, some customers have. 

So you can use an external by using NAT or an internal by using NAT, forcing everyone to use this server and no other service.

In the end, if you use NAT or a NTP Server is technically the same. The client gets a NTP response from someone you trust. 

If you want to be the own NTP server, like above, you need to make sure, you complain with certain services anyway. 

Fair Point. 
I missed to clarify where I'm coming from. I'm referring to the commonly recommended scenario 1 from this post (and I implied you wer referring to it as well):  Sophos Firewall: Using NAT to achieve NTP proxy like functionality  (scenario 2, has later been added)

I'm not negating the point of having a "Any to WAN -> NAT to internal NTP" NAT-rule. Such a rule makes sense and should absolutely be setup, if you care about NTP in your network.

yes, NTP servers need some care. If you don't want to maintain them yourself, you need an appliance.
But it does not change the fact, that you had this feature in the previous product, which is now missing. And an additional service/appliance I need to implement and manage and take care of.

So at the moment, talking to most customers, they have one of this: 
AD server (which services time)
Special appliance for NTP with a radio to receive NTP (specific use case of compliance). 
Not having anything and not "caring" about NTP. 

In any of those cases, we can fully complain this with a NTP NAT redirect. 

An NTP server on SFOS has (in my eyes) 0 value. But costs money to develop and implement in SFOS (Service, hardening, Webadmin implementation etc.). 
Using Sophos resources to implement this feature for "0 value" to the customer - Is maybe not the best investment.

Maybe in the future, this will be implemented, but as you can see in V21.0, Sophos is implementation also new features like 3th Party feeds and other SD-WAN Implementations - which adds a value to the customer. 

I prefer no access

I prefer no access