In practice, it is rarely that simple.

From what we see working with customers, renewal is usually part of a larger process. It involves multiple steps, and if something is missed, it can lead to warnings or even downtime.

Why frequent renewal is now required

SSL certificates no longer last for 398 days.

As of March 2026, certificates can be issued for up to 200 days. This is shorter than before, and it is getting shorter.

The idea is simple. Shorter lifespans reduce risk. If something goes wrong, it limits how long a certificate can be misused.

In reality, many organisations are already moving to even shorter cycles. This is usually supported by automation.

From experience, teams that still manage certificates manually tend to struggle more as these timelines get shorter.

Renewal ensures:

• The website remains secure
• Continued browser trust
• Certificate details remain up to date

Here is what happens behind the scenes:

Step 1: Creating a new request

 When a certificate is renewed, the system will usually generate a new security key.

This key is kept private. It is what protects the connection between the website and its visitors.

A request is then created using this key. This is often called a certificate request.

It contains basic details about the website, along with a public version of the key.

In most environments, generating a new key is considered good practice. It reduces the risk of older keys being reused over time.

Step 2: Checking your identity

Next, the Certificate Authority needs to confirm that you still control the domain.

This is an important step regardless of the issuing Certificate Authority. It prevents someone else from requesting a certificate for your website.

For Domain Validation, this can be quick.

You might be asked to do any of the following:

• Approve an email sent to your domain
• Add a DNS record
• Upload a small file to your website

For Organisation Validation, there are more checks.

These may include verifying your business registration and confirming your company details.

For Extended Validation, the checks go even further. The Certificate Authority will review your organisation more thoroughly.

Step 3: Issuing the new certificate

Once everything is verified, the certificate is issued.

You will receive a few files. Each one plays a role in establishing trust.

These include:

• Your main certificate
• Intermediate certificates
• The root certificate (already trusted by browsers)

Together, they form what is called a certificate chain.

If this chain is not set up properly, browsers may show warnings even if the certificate itself is valid.

There is also something happening in the background that most people do not see.

New certificates are recorded in public logs. This adds an extra layer of transparency, allowing browsers and security systems to detect suspicious or unauthorised certificates.

Step 4: Installing the certificate

The new certificate then needs to be installed.

This usually means replacing the old certificate and making sure the full chain is configured correctly.

In smaller setups, this might be straightforward.

In larger environments, it can be more complex. Certificates may need to be updated across multiple servers, load balancers, or cloud services.

This is where we often see issues. A certificate is renewed, but not deployed everywhere it needs to be.

When someone visits your website, their browser runs a series of checks.

This happens in seconds.

The browser will:

• Check that the certificate is valid
• Confirm it has not expired
• Verify the issuing authority
• Match it to the domain

It will also validate the full certificate chain.

When an SSL certificate expires, the connection is no longer secure, resulting not only in downtime, but also in exposing systems to potential cyber threats and causing reputational damage. This is why timely renewal is critical.

A quick note on automation

With shorter certificate lifespans, manual processes become harder to manage.

This is why many organisations are moving towards automation.

In most modern setups, certificates can be requested, renewed, and installed automatically in the background.

From what we see, this significantly reduces missed renewals and operational overhead.

Automation helps to:

• Renew certificates on time
• Handle shorter validity periods
• Reduce manual errors

Solutions like Next-Generation SSL are designed to manage this centrally.

Instead of tracking certificates individually, teams can monitor and manage everything in one place.

Final thoughts

SSL renewal is not just a routine task.

It is something that needs to be managed continuously.

As environments grow, manual handling becomes difficult to maintain. This is where many teams start to feel the strain.

More organisations are now treating certificates as part of their ongoing security operations, rather than as something handled only occasionally. If your team is facing similar challenges, it may be worth looking at how an automation solution like Next-Generation SSL can help to simplify operations and reduce risk.

The post SSL Certificate Renewal: What Actually Happens Behind the Scenes appeared first on Netrust.

These days, almost everything relies on cryptography in one way or another, whether it is SSL/TLS, digital signing, identity systems, or encryption.

But when people talk about security, they usually focus on the algorithm or the technology itself. What often gets overlooked is something much more practical: how the keys are managed.

Because no matter how strong the encryption is, if the keys are poorly handled, the whole thing can fall apart.

What is security key management?

In simple terms, it is the way cryptographic keys are handled from start to finish.

That includes:

• how the keys are created
• where they are stored
• who is allowed to access them
• when they should be rotated
• how they are revoked or destroyed

It sounds straightforward, but this is one of the most important parts of any cryptographic system.

Why does it matter?

A lot of security problems in real environments are not caused by weak encryption. They happen because keys are not managed properly.

For example:

• private keys are stored in plaintext
• certificates expire without anyone noticing
• the same keys are kept in use for too long
• nobody has a clear view of where certificates are deployed

Once a key is exposed or mishandled, the impact can be serious.

An attacker may be able to impersonate a system, decrypt sensitive information, or get around the trust built into the environment. And when it reaches that stage, the problem is no longer minor. It becomes a full compromise.

What good key management looks like

First, keys should be generated properly using strong standards and in a secure environment. For more sensitive use cases, this is usually done inside an HSM.

Second, private keys need to be stored securely. They should never be left exposed or kept in insecure locations. Depending on the setup, this could mean using HSMs, TPMs, or a cloud KMS.

Third, access must be controlled properly. Not everyone should be able to view or use sensitive keys. Good practice includes role-based access control, separation of duties, and stronger approval controls for critical actions.

Then there is the lifecycle itself. Keys should be rotated regularly, replaced before expiry, and retired properly when they are no longer needed.

The challenge in real life

In theory, all of this sounds manageable. In reality, it often is not.

Certificates end up scattered across servers, load balancers, applications, and cloud platforms. Different teams may be using different CAs. Some environments still rely heavily on spreadsheets or manual tracking. After some time, nobody has a complete picture anymore.

That is usually when problems start showing up, such as expired certificates, unmanaged keys, duplicated certificates, or avoidable outages.

This is why centralised management and automation matter so much. At a certain scale, manual handling is just not enough.

What actually helps

In practice, a few things make the biggest difference: using HSMs for critical keys, centralising certificate and key management, reducing reliance on manual tracking, automating renewals and monitoring, limiting access to authorised personnel, and ensuring key usage is logged and auditable.

These are not complicated measures, but they are the ones that make a real difference in reducing risk.

The organisations likely to struggle in the PQC transition are not those lacking quantum expertise.

Final thoughts

At the end of the day, key management is really about control and visibility.

You can have strong encryption and a solid security design, but if the keys are not managed properly, the whole setup is at risk.

This is why key management is not just an operational concern. It is a critical part of overall security.

Follow us on LinkedIn for the latest happenings/updates.

The post Security Key Management: The Backbone of Digital Trust appeared first on Netrust.

At Netrust, my client base focuses on Singapore and the wider APAC region, which means my day-to-day is anything but predictable.

The Morning Sprint (and the Caffeine)

My day usually starts with a quick scan of the regional landscape. Because I handle the APAC market, I might be answering a technical query from a partner in Thailand at 9:00 AM, then pivoting immediately to a high-level strategy session for a Singapore government project an hour later.

It’s not just about “selling.” I spend a lot of time playing detective, digging into a client’s infrastructure to find out why their existing security is failing them. Are they struggling with manual document signing? Is their certificate management a mess? That’s where the “consultant” part of my title actually earns its keep.

Turning Chaos into Compliance

When I’m in these meetings, I’m not just talking about abstract concepts. I’m matching real-world headaches with the specific solutions we have at Netrust. Here are the three heavy hitters that usually dominate my conversations:

• Managed CA Services: This is the heart of what we do. As Singapore’s only IMDA-accredited Certificate Authority, we provide what “root-of-trust” companies crave. I often talk to banks or government agencies that need high-assurance identities. Whether they want us to host it or need an internal PKI built on their premises, we provide the legal certainty that their digital IDs actually mean something.
• Certificate Lifecycle Management (CLM): If you want to see a CISO’s blood pressure rise, mention “expired SSL/TLS certificates.” With public TLS certificate lifespans dropping to 47-day cycles by 2029, manual tracking in spreadsheets is a recipe for disaster. I spend a lot of time demoing our CLM platforms, showing how it automates discovery, renewal, and provisioning so the lights stay on without a human having to intervene.
• nSignHub: This is the “productivity hero.” It’s our cloud-based signing workflow. I love showing this to teams that are still chasing people for physical signatures. nSignHub handles everything from “Sign with Singpass” to Netrust Secure Electronic Signature, which is AATL-trusted and recognised globally by Adobe and Microsoft. It turns a week-long paper trail into a five-minute digital process.

The APAC Hustle

The best part of the job is the variety. One day, I’m navigating the specific regulatory requirements of the Singapore Electronic Transactions Act (ETA), and the next, I’m helping a regional enterprise scale their certificate authority infrastructure across three different time zones.

It’s a busy life, sure. There are days when the RFPs feel endless, and the technical requirements are a mile long. But there’s a specific kind of buzz you get when a complex solution finally clicks into place.

The Verdict

Life at Netrust isn’t about sitting behind a screen all day. It’s about being in the thick of the APAC digital transformation. It’s fast, it’s furious, and it’s incredibly rewarding to be the person who helps turn “We need to be secure” into “We are Netrust-secured.”

If you want to see me in action (or just want to see if I can actually explain PKI without using a 50-deck PowerPoint), let’s talk! Contact us at https://www.netrust.net/contact-us/.

Follow us on LinkedIn for the latest happenings/updates.

The post High Stakes and Digital Trust: My Reality as a Netrust Presales Consultant appeared first on Netrust.

Together, they’re disruptive.

The first is well known: quantum computing is moving from theoretical research into practical engineering. Whether we think it will take 5 years or 15, one thing is clear: the public key algorithms protecting today’s internet were not designed for a quantum-capable adversary.

The second is more immediate and operational: the CA/Browser Forum has formalised the progressive reduction of SSL/TLS certificate validity periods, culminating in a maximum lifespan of 47 days by 2029.

Forty-seven days.

That’s not a typo.

If you run a public website, APIs, cloud workloads, or anything customer-facing, this isn’t just a compliance detail. It’s an operational shift.

Why This Combination Is Different

Let’s break it down.

1. The Post-Quantum Shift Is About Crypto Agility

Most organisations are not worried about quantum computers breaking RSA tomorrow.

What they should be thinking about is this:

When PQC becomes production-ready and mandated, how fast can you transition?

If your certificate infrastructure is rigid, manually managed, and scattered across business units, then the real risk isn’t quantum; it’s organisational inertia.

Crypto agility is not about deploying PQC today.

It’s about ensuring you can switch when the time comes.

2. 47-Day Certificates Change the Operating Model

For years, certificate management was treated as an administrative task. A renewal reminder here, a spreadsheet there.

That model doesn’t survive a 47-day validity world.

At 47 days:

• Renewals become constant
• Manual tracking becomes error-prone
• Outage risk increases exponentially
• Audit and compliance complexity grows

Shorter lifespans are good for ecosystem security.

But they demand automation.

The Real Issue Isn’t PQC. It’s Lifecycle Management.

Based on what we observe across industries, the real bottleneck isn’t algorithm readiness.

It’s visibility.

Many organisations don’t have:

• A complete inventory of their SSL/TLS certificates
• Centralised expiry monitoring
• Automated issuance and renewal workflows
• A structured plan for algorithm transition

And without those fundamentals, talking about post-quantum migration is premature.

You can’t modernise cryptography if you don’t even know where it’s deployed.

What Forward-Looking Organisations Are Doing

The more mature organisations we observe are taking a phased approach:

Step 1: Gain Full Certificate Visibility

Build a complete inventory across public websites, internal systems, cloud, containers, and load balancers.

Step 2: Automate the Lifecycle

Move away from manual renewals. Integrate issuance and renewal into DevOps and infrastructure pipelines.

Step 3: Design for Algorithm Flexibility

Ensure that certificate management systems are not tightly bound to a single algorithm. Prepare for hybrid (classical + PQC) deployments when standards stabilise.

Step 4: Monitor Industry Signals

Track NIST PQC standardisation, browser support, root program policies, and regulatory guidance to be prepared.

A Subtle but Important Shift

Historically, SSL/TLS certificates were treated as point-in-time security artefacts. From now on, they need to be treated as continuously managed cryptographic assets.

The 47-day timeline accelerates this.

The post-quantum era makes it non-optional.

Final Thought

The organisations likely to struggle in the PQC transition are not those lacking quantum expertise.

They’re the ones still managing certificates manually.

If there’s one practical takeaway from both trends, it’s this:

Before thinking about quantum-safe algorithms, make sure your certificate lifecycle is automated, visible, and crypto-agile. Everything else builds on that foundation.

If you’re assessing your certificate lifecycle readiness or thinking about crypto agility, we’re always happy to share what we’re seeing across the industry. Contact us today.

Follow us on LinkedIn for the latest happenings/updates.

The post The 47-Day Certificate Era and the Post-Quantum Reality: Are We Ready? appeared first on Netrust.

SSL/TLS encrypts data in transit, but it does not guarantee end-to-end Confidentiality, Integrity and Authenticity (CIA) once the email message reaches intermediate systems or the mail servers.

To have a secure email is to ensure that all sensitive information remains guarded throughout its entire lifecycle, from the moment it is sent out by the sender till the recipient opens it. With the increase in remote work, more stringent regulatory requirements and a growing number of data breaches, organisations must move beyond SSL/TLS encryption to achieve higher email security postures.

We will explore why SSL/TLS alone is never enough, and how organisations can strengthen email security postures by using comprehensive encryption strategies.

Many believe that once email traffic is protected by SSL/TLS, the communication is secure. However, in reality, SSL/TLS only encrypts the part where the email is being transmitted between mail servers. So, once the email reaches a server, it will typically be decrypted and stored in plain text, making it vulnerable to attacks such as internal threats, compromised mailbox or server breaches.

A straightforward example would be sending a confidential letter in a locked courier truck and leaving it unsealed during storage in a warehouse. If adversaries gain access to the server, or if the emails are forwarded, archived or backed up, the original SSL/TLS encryption no longer applies.

As organisations increasingly exchange sensitive information such as contracts and financial data, only relying on SSL/TLS exposes them to compliance risks and data leakage. A stronger, more holistic email encryption approach is needed to address these gaps.

1. End-to-End Email Encryption

Emails will be encrypted at the sender’s side, and remain encrypted till decryption is done by the recipient. This will ensure only the intended recipient can decrypt and read the email content, preventing others, including mail servers, from accessing the email content.

Modern email encryption solutions can integrate seamlessly with common platforms like Outlook and Gmail. For external recipients who do not use the same encryption system, secure methods such as email verification or one-time passcodes can be used to authenticate the recipient and allow secure decryption through a browser.

By encrypting the email message itself, rather than just the transmission channel, organisations can ensure total confidentiality of the email message from sender to recipient. This significantly reduces exposure to server-side breaches and insider threats.

2. Encryption at Rest

Data at rest, such as archives and backups require encryption as well, to prevent attackers from gaining access to the mail server or storage system. This encrypted data remains unreadable without the proper keys for decryption.

3. Identity-Based Encryption and Key Management

A combination of Identity-Based encryption, centrally managed key systems, and hardware security tokens to simplify key management. Associating keys with user identities while storing private keys in USB tokens that cannot be replicated will help to prevent unauthorised decryption and support secure user onboarding and offboarding.

4. Secure Email Gateways and Policy Enforcement

Secure email gateway solutions with built-in Data Loss Prevention (DLP) capabilities help organisations enforce encryption policies automatically. These systems can inspect email content and apply encryption based on predefined rules.

For example, emails containing personal data (PII) or financial information can be automatically encrypted before being sent, whether to internal or external recipients. This reduces reliance on users to make security decisions and ensures consistent protection across the organisation.

Best Practices / Tips

• Classify sensitive email content so encryption policies are applied automatically and consistently.
• Encrypt emails both in transit and at rest to cover the full data lifecycle.
• Secure external communications by integrating a third-party application for encrypted email exchanges with partners and customers with ease and usability.
• Centralise key management to reduce complexity and minimize human error.
• Audit and review DLP policies regularly to align with evolving threats and compliance requirements.

Lastly, and the most important point:

• Educate employees on the importance of email security to prevent data leakage.

These recommended practices help organisations to maintain a strong email security posture without burning out users or IT teams.

Conclusion

SSL/TLS is an important foundation for email security, but it is no longer sufficient on its own. Organisations must adopt strong encryption strategies that protect data end-to-end, at rest and across all email workflows. With comprehensive encryption, organisations can reduce breach risks, strengthen compliance and build trust in digital communication.

Netrust has been a trusted cybersecurity partner and solutions provider since 1997. We have decades of experience in end-to-end cryptographic processes, including encryption and decryption. Every bit of experience we have builds up to the megabytes of confidence you can place in us. Contact us today for a consultation on your encryption needs.

Follow us on LinkedIn for the latest happenings/updates.

The post Why Enterprises Need Secure Email Encryption appeared first on Netrust.

On 11 April 2025, the CA/Browser Forum — the industry body that governs SSL/TLS certificates — voted to progressively shorten certificate validity periods. The end point: a maximum of 47 days by 2029. The first milestone already hit this month.

For a change, I’m not writing this to sell or promote anything. I’m writing this because I’ve been in the PKI and digital security space for a long time, and I’ve seen how these kinds of changes catch organisations off guard when they’re buried in forum announcements and technical documentation that most business leaders never read.

So here’s the plain-English version.

What changed, and when

Previously, organisations can obtain an SSL/TLS certificate valid for up to 398 days — a little over 13 months. That’s the window you have before you need to renew.

Under the new schedule approved by Apple’s proposal at the CA/Browser Forum, that window shrinks significantly:

The first cut — to 200 days — applies from 15 March 2026. That’s now.

If your organisation is renewing or issuing new certificates from this point forward, you’re already operating under the new rules.

Why did this happen?

The reasoning is sound, even if the timing creates inconvenience. Shorter certificate lifespans reduce the window of exposure if a certificate is ever compromised. If an attacker gets hold of a certificate, a 47-day lifespan limits how long they can exploit it.

There’s also a push to get organisations away from manual, ‘set it and forget it’ approaches to certificate management — which, frankly, most organisations still rely on.

The industry is essentially forcing automation. The question is whether your organisation is ready for it.

What this means at the leadership level

Most of us as leaders are not the ones managing certificates day to day. That sits with your IT or security team. But the decisions that come out of this change will land on your desk — because the response options each carry trade-offs that go beyond the technical.

The math is straightforward. If your organisation manages 50 certificates today and renews them once a year, that is roughly 50 renewal actions annually. At 47-day validity, the same estate requires close to 400 renewal actions a year. Some teams, when they hear this, immediately ask: can we just hire more people to handle the increased frequency?

It is a fair instinct, but it misses the real problem. The issue is not volume alone — it is complexity and visibility. Certificates are often reused across multiple systems. It is not best practice, but it happens, and it happens a lot. When that is the case, a single certificate expiring does not just affect one service. It can cascade across everything it was deployed to — and the team may not even know where all the instances are.

Most certificate-related outages I have seen are not due to malicious/lazy administrators. They happen because a certificate was tracked in a spreadsheet or an internal document, got buried in a long list, and either was missed entirely or was renewed in one place but not updated everywhere it was deployed. Adding headcount to a manual process does not eliminate that risk — it just means more people are working from the same incomplete picture.

The question to ask your team is not “do we have enough people?” It is “do we have full visibility of every certificate we own, and do we know everywhere each one is deployed?” If the honest answer is no, that is the gap to close first.

My own experience trying to automate this

I want to share something candidly, because I think it is more useful than giving advice I have not personally tested.

Netrust is not a large organisation. We are not a bank with a dedicated security operations team of fifty people. And even so, pushing for automation internally has not been straightforward. Automating anything requires people to change how they work — and change is uncomfortable, even when everyone agrees it is the right direction. There are internal inertias to work through, legacy processes to untangle, and moments where it feels easier to just keep doing things the old way.

I share this not to paint a bleak picture, but because I think leaders who are navigating this need to go in with realistic expectations. Automation is the right answer. Getting there requires someone at the top to hold the line on it — because the path of least resistance will always be to patch things manually and move on.

Interestingly, a recent review with my team surfaced something worth noting. It is actually the smaller, more nimble organisations that are showing the most eagerness to move on this. Perhaps because they have fewer legacy systems to untangle, or because the decision chain is shorter — but whatever the reason, they are not waiting. If anything, that should give the larger organisations pause.

If you are a CIO or CISO reading this, this is your initiative to champion — not to delegate and forget. The organisations that will handle the 2027 and 2029 milestones well are the ones where someone at the leadership level decided early that manual was not good enough.

What good looks like

The answer is not a product — it is a capability. The organisations that will navigate this well are the ones that have moved from reactive to systematic. Certificates should not be something your team scrambles to deal with. They should be something your infrastructure handles on its own, with your team only stepping in when something genuinely needs attention.

When I think about what that looks like in practice, I would ask four questions of any approach your team puts forward:

• Can we see every certificate we own, across every system, in one place — without someone having to compile a spreadsheet?
• Does renewal happen automatically, well before expiry — or does the process only start when someone notices a reminder?
• When a certificate is renewed, is it updated everywhere it is deployed — or just in the place someone remembered to check?
• If something looks anomalous or falls outside policy, does the team find out proactively — or after something breaks?

If the honest answer to any of those is “we are not sure” or “it depends on who is on duty” — that is where the conversation with your team needs to start. This is not just a technical decision. It is an operational resilience decision. The CIO or CISO who surfaces this to the board before something breaks is in a very different position from the one who has to explain an outage.

Signing off — for now

I have been speaking with peers across sectors — education, government, financial services — and the pattern is consistent. Most organisations know something is changing. Not many have sat down to work out what it actually means for their environment, their team, and their processes.

I am happy to share my own journey on this — the decisions we made, the pitfalls we hit, what I would do differently — over coffee or when we cross paths at industry gatherings. These are the conversations I find most useful, and I suspect others do too.

Till the next time we meet.

Eugene Lam is Deputy CEO of Netrust, Singapore’s only IMDA-accredited Certificate Authority and Asia’s first public CA. Netrust has been helping organisations manage PKI and digital certificates since 1997.

Reference: CA/Browser Forum Ballot SC-081v3 · cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/

The post Your SSL Certificates Are About to Expire a Lot More Often. Here’s What That Means for Your Organisation. appeared first on Netrust.

In real-world environments, certificate renewal may seem completed from the issuing CA’s perspective. This does not guarantee successful provisioning, which may result in application failures, service outages, or authorisation issues. Such issues might not be detected immediately. They are usually detected only after a service or server restart activity or routine maintenance. This adds more pressure to the maintenance team for remediation.

The cause of the certificate renewal failure is usually not due to the certificate itself. They are caused by dependencies around keys, permissions, trust chains and system integration. This post shares some of the common reasons for the certificate renewal failure and what teams should pay attention to when the certificate renewal is operated at scale.

The complexity behind certificate renewal

In theory, certificate renewal sounds straightforward: replacing an expiring certificate with a new certificate.  However, certificates in enterprise environments usually contain dependencies. They are tied to private keys, service identities, HSMs, load balancers, databases, and multiple downstream systems.

Renewing a certificate not only updates the certificate information. A new key pair may be generated, permission may be re-evaluated, or the trust chain may differ, especially when the issuer changed. Those changes do not always cause immediate failure, and this makes them more difficult to detect during routine checks.

Common Causes of Certificate Renewal Failures

1. Key Pair Changes Are Not Fully Understood

A very common cause for the failure is whether the renewal reuses the existing key pair or generates a new one. This distinction matters, especially during the troubleshooting phase.

When a certificate is used for encryption, signing or database protection, changing the key pair can have downstream effects. Data encrypted with the old key still requires the old key for operation and accessibility. In an environment where an HSM is used to store the private key, key lifecycle management becomes even more crucial due to strict access controls and policies.

2. Private Key Access Breaks After Renewal

It is not uncommon for certificates to renew successfully while applications fail to access the private key afterwards. This often comes down to service accounts, identity mappings, or permission changes that occur during renewal.

These issues frequently appear only after a restart or failover, when services attempt to rebind to the key. At that point, troubleshooting becomes more difficult, especially in production environments with tight recovery timelines.

3. Trust Chain Differences Are Overlooked

If the full trust chain isn’t updated across the environment, renewed certificates may fail validation. Client or upstream components may reject the certificate even if this certificate is technically valid.

This is a very common issue in environments where Strict TLS validation is imposed, or where multiple network layers, such as load balancers and reverse proxies, exist.

4. Automation Focuses on Issuance, Not Validation

In large environments, automation services usually focus on certificate issuance. While logs may confirm a successful renewal, they do not verify that the application has successfully adopted the updated certificate. A mandated post-renewal validation should be in place. This process checks the active binding, key access, or live TLS handshakes. Those issues may remain hidden until the next operational event triggers a failure.

5. Renewals Are Not Tested Under Operational Scenarios

Certificate renewals are usually validated only under normal conditions. During failovers, patching exercises or disaster recovery, it is usually overlooked or tested superficially.

As a result, the certificate renewal process that seems reliable during day-to-day operation may fail when the system is under stress. These are precisely the moments when certificate-related issues cause the most impact.

Practical Considerations for Enterprise Teams

From an operational perspective, a few practices consistently help reduce renewal-related issues:

• Be explicit about whether renewals reuse existing keys or generate new ones.
• Always verify private key access after renewal, not just certificate presence.
• Ensure intermediate certificates and trust chains are deployed consistently.
• Monitor both renewal status and deployment success.
• Test renewals during restarts, failovers, and planned maintenance windows.

These steps do not eliminate complexity, but they significantly reduce surprises.

Conclusion

In the enterprise environment, certificate renewal is rarely due solely to expired certificates. They are usually the result of hidden dependencies across keys, permissions, identities and trusted chains. Automation helps, but it does not replace the need for visibility and validation. At least for now.

When a certificate renewal is managed as part of a full lifecycle rather than as background tasks, outages can be reduced, avoided, and prevented. This becomes more important as the enterprise environment scales and increases in complexity. In addition, with the shortening of the TLS certificate to 47 days, the renewal frequency increased significantly. This greatly reduced the response time for manual intervention, ad-hoc troubleshooting or operational error. As such, a more robust automation, proper lifecycle management and end-to-end validation should be in place for the certificate renewal process. Contact us today for a consultation today.

Follow us on LinkedIn for the latest happenings/updates.

The post Why Certificate Renewals Fail in Enterprise Environments appeared first on Netrust.

Let’s start with a primer video, where we will use letter wax seals to demonstrate what a digital signature is.

Now that you know what encryption is, let’s fill in the remaining information you will need to know to work with it. Don’t worry if the rest of the article seems technical, you just need to know enough to select the most suitable components for your use case.

Use Cases and Algorithms

There are two types of encryption algorithms, symmetric and asymmetric. For ease of understanding, symmetric algorithms use the same key for encryption and decryption, whereas asymmetric algorithms use a key pair instead. A key pair (consisting of a “private key” and “public key”) can be imagined as a digital conjoined twin, tightly bound to each other at birth, with one half used for encryption and the other half for decryption.

They are suitable for different purposes. When considering encryption, it is recommended to start with a symmetric algorithm as the base. They are fast and can handle any amount of data.

This approach is typically enough for most use cases where the intention is to encrypt data to transfer to the archive, or to another internal application. It is expected that the internal application will have the means to use the same key or a securely shared copy of it to decrypt the data.

For transfer to external parties, the same approach could technically work so long as the key can be securely and secretly shared with the external party. It would not do, for example, to send the key via email. Alternatively, asymmetric algorithms would serve well in this scenario.

This approach covers the remaining use cases in which encrypted data needs to be sent out. You will need to get hold of the recipient’s public key or digital certificate if they have it. Yes, it is the same digital certificate used for digital signatures.

Now, which actual algorithm do we go with? Typical industry standard is to use the best open standard algorithm at the time, which is AES for symmetric and RSA/ECC for asymmetric at the point of writing. These algorithms have been thoroughly analysed by the community. Do avoid the trap of thinking of using an obscure or custom algorithm, they add risk without necessarily adding strength to the equation.

Also, ensure that some crypto mode is used together with the symmetric algorithm. The strongest available today unencumbered by patents, is GCM. If some of the legacy components in the ecosystem are unable to handle that, CBC is a good fallback. Do avoid ECB as that is effectively running without a mode.

The reason is best explained by this image from Wikipedia ^[1]. Modes add some jitter into the process so that each time the encryption process is run, different results are produced with the same source data. Yet it is still able to decrypt back to the original source data.

Key Generation and Storage

We have talked about the keys used in symmetric algorithms above. Needless to say, it should be securely generated using a secure random byte generator and access to it should be restricted except for the application doing the cryptographic processes.

The keys need to be rolled over periodically as well. This means old keys are archived (not deleted!) and new keys generated to use on future data encryption. As the encrypted data needs to be accessible in the future, the old keys need to be stored for as long as the data remains in the picture. In some use cases we have seen, this could be 7 years, or as long as 99 years.

For the best security it is recommended to generate and retain the key within a Hardware Security Module (HSM) as it provides both the generation and storage facilities in one hardware package. There are also means to securely backup and restore the keys in the event of disaster recovery or migration to other environments. If your application is on Cloud, there are HSM equivalents or Key Management Services (KMS) which serve a similar role on the major Cloud providers.

For asymmetric algorithms this is not an issue, as public keys or digital certificates are designed to be shared to the party that wishes to encrypt data for you.

Implementation and Applications

Theory is all fine and dandy, but the devil is in the (implementation) details. Cryptography is one of those things where one critical misstep could render the process meaningless. For example, if the encryption key is sent out via an insecure process, it compromises all past and future data encrypted using that particular key.

There are off the shelf applications that can handle the encryption process, but these typically only cover a specific use case or ecosystem. One example is email encryption (S/MIME) through Microsoft Outlook.

For other cases, especially if encryption is required for your application’s data, a custom solution should be expected. This may use an existing cryptographic API product or library, or may be made to measure entirely.

Conclusion

There is a lot more to know under the hood, but contrary to common belief, you do not need to know everything to work with data encryption. What we have laid out above should be sufficient to get you started, though it is strongly recommended to seek a consultation to determine the best solution for your requirements. We are also including answers to some frequently asked questions below that we have encountered before.

Netrust has been a trusted cybersecurity partner and solutions provider since 1997. We have decades of experience in end-to-end cryptographic processes, including encryption and decryption. Every bit of experience we have builds up to the megabytes of confidence you can place in us. Contact us today for a consultation on your encryption needs.

FAQs

• Can I encrypt just a section of the data?

Certainly. Off the shelf applications would not support this, though so the custom implementation would have to be able to cut, encrypt and piece the data blocks back together as required.

• I have already encrypted a file, but then I lost my key/token! What should I do?

The first step is to determine how the key/token was lost. If there are reasonable grounds to believe it has been compromised, you will need to assume that all data encrypted with the lost key is compromised and respond in accordance with your country’s data privacy guidelines, such as the PDPA.

If the key is not compromised, you can look into restoring the key from backup. This should already be defined in the disaster recovery procedures before the system goes live. If the keys are not backed up or cannot be restored, then access to the data is effectively lost.

There is no convenient backdoor to restore access, this is exactly how cryptographic systems are intended to work.

• Can someone else see the data?

No, encrypted data is effectively scrambled. The only way anyone can see the original data is if they know the correct algorithm, modes, and processes that the file is encrypted through, and have the correct key to run said decryption process.

• I am sending the data to an external party; how can they confirm that this data came from me?

Encryption does not carry the sender’s identity. To achieve this, the data can be digitally signed first before it is encrypted and sent. The digital signature (Read up more on our article on Explaining Digital Signatures through real world examples) will carry the sender’s identity.

• Can digital signatures and encryption be used together?

Certainly, they are not mutually exclusive.

• Can someone else tamper with the data?

It is not possible to edit the data without corrupting the original. What that means is once edited, decryption can still be attempted, but the original data cannot be reconstructed. What is likely to emerge would be gibberish data.

Reference table on the differences between Digital Signatures and Encryption.

[1] Image source: https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#ECB

Follow us on LinkedIn for the latest happenings/updates.

The post Explaining Encryption through real world examples appeared first on Netrust.

In today’s digital-first world, the line between application development and AI integration has vanished. While this fusion drives innovation, it also creates a complex and expanded attack surface. How can organizations protect their software without slowing down progress? The answer lies in a unified approach to application security. Traditional, siloed tools are no longer enough to manage the intertwined risks of open-source dependencies, code vulnerabilities, and the unique threats targeting AI models. A modern security strategy requires a holistic platform that provides end-to-end visibility and control.

Now that you know what a digital signature is, let’s fill in the remaining information you will need to know to work with it.

The Challenge: Why Traditional Security Falls Short

Many IT teams today are playing a constant game of catch-up. They use one tool for scanning open-source libraries (SCA), another for analyzing their own code (SAST), a third to protect their new AI features, and perhaps manual consultants for periodic penetration testing. This fragmented approach is like trying to assemble a car with four different sets of instructions—it’s inefficient, creates blind spots, and leaves critical connections unsecured. The reality is that a vulnerability in a third-party library can be exploited to poison an AI model, or a weak API can expose sensitive data through a generative AI chatbot.

This complexity leads to several common problems:

• Vulnerability Overload: Teams are flooded with alerts from multiple tools, with no clear way to prioritize what truly matters.
• Siloed Visibility: Security, development, and operations teams lack a shared understanding of risk across the application lifecycle.
• Emerging AI Threats: Traditional firewalls and scanners are not designed to detect prompt injection, model manipulation, or data leakage from Large Language Models (LLMs).
• Manual Bottlenecks: Periodic, manual security tests can’t keep pace with rapid development cycles, leaving new features exposed.

The Solution: A Three-Layered Security Strategy

To address these challenges effectively, organizations need an integrated platform that secures the entire digital ecosystem. This involves a three-layered approach that covers the software supply chain, the AI models themselves, and proactive threat discovery. Scantist delivers this through its unified suite of AI-driven solutions.

1. Secure Your Foundation: AppDefender for DevSecOps

Everything starts with the code and its dependencies. Before you can secure your AI, you must secure the application it lives in. AppDefender, Scantist’s flagship DevSecOps platform, provides a solid foundation by securing your entire software supply chain.

• What it is: A comprehensive platform that combines Software Composition Analysis (SCA), Static Application Security Testing (SAST), and deep binary analysis.
• Why it matters: It gives you a single pane of glass to manage open-source governance, identify vulnerabilities in your own code, and ensure the integrity of your software from the first line of code to the final build. By automating DevSecOps orchestration and real-time SBOM management, it eliminates security noise and allows developers to focus on fixing what matters.

2. Protect Your AI: AIDefender for LLM Security

Once your application foundation is secure, the next layer is to protect the AI models and agents running on it. Generative AI introduces novel risks that require specialized defenses. AIDefender is purpose-built to be the security gateway for your enterprise AI.

• What it is: A dedicated AI security solution that protects against emerging threats targeting LLMs and generative AI tools.
• Why it matters: AIDefender prevents prompt injection attacks, detects and blocks sensitive data leakage, and monitors for model manipulation or poisoning. It ensures your AI implementations remain secure and compliant with evolving governance frameworks, allowing you to innovate with confidence.

3. Think Like an Attacker: PAIStrike for Automated Penetration Testing

The final layer is to shift from a defensive posture to a proactive one. Instead of waiting for attackers to find your weaknesses, you need to find them first. PAIStrike revolutionizes this process with its automated, AI-powered penetration testing.

• What it is: An intelligent “red team” tool that uses multi-agent AI to automatically perform end-to-end penetration testing, just like a professional hacker.
• Why it matters: PAIStrike runs 24/7, continuously searching for vulnerabilities across your network, code, and infrastructure. It automates reconnaissance, vulnerability assessment, and exploit simulation, providing a true understanding of your security posture from an attacker’s perspective.

Best Practices for Holistic Security

Adopting these tools is the first step. To ensure lasting success, integrate them with a security-first mindset. Here are a few best practices:

• Shift Security Left, and Right: Integrate security checks early in the development process with AppDefender, but also continuously test your live environment with PAIStrike.
• Embrace Full-Stack Visibility: Use a unified platform to connect the dots between a vulnerability in a library, a risk in an AI model, and a potential exploit path.
• Automate Everything You Can: From SBOM generation to compliance reporting and penetration testing, automation frees up your team to focus on strategic risk reduction.
• Treat AI as a Unique Domain: Recognize that securing AI is not the same as securing a traditional application. Deploy specialized defenses like AIDefender.

Conclusion & Call to Action

In the age of AI, a fragmented security strategy is a losing one. Protecting your digital ecosystem requires a unified, intelligent, and proactive approach. By securing your software supply chain, protecting your AI implementations, and continuously testing your defenses, you can build true digital resilience.

Ready to simplify your security and focus on what matters? Contact Scantist today to learn how our unified platform can protect your applications and AI.

The post Secure Your Future: A Guide to Unified Application and AI Security appeared first on Netrust.

Let’s start with a primer video, where we will use letter wax seals to demonstrate what a digital signature is.

Now that you know what a digital signature is, let’s fill in the remaining information you will need to know to work with it.

Use Cases

In our experience, most use cases revolve around document agreements and thus PDF signing. In fact, digital signatures can be regarded as the next evolutionary step up from electronic signatures, which itself has evolved from handwritten signatures. Given the digital nature, it is more versatile and can protect not only documents, but also other use cases such as signing non-document data or protecting data for archival.

For document agreements, digital signatures signed using digital certificates from Netrust ^[1] enjoy Legal Presumption under the Electronic Transactions Act. Simply speaking, documents with valid Netrust signatures will be accepted as evidence in the court of law without unnecessary scrutiny.

Standards

The process of creating a digital signature follows standards, the prevalent standard now being PAdES for PDF signatures. For non-PDF files, the CAdES standard can be applied. When engaging with the vendors, it would be best to put compliance with standards as one of the requirements. This also helps prevent vendor lock-in.

Applications

As the technology and processes are already mature, digital signatures can be easily created with off the shelf applications. For small amounts or ad hoc signatures, Adobe Reader is readily available. You will however, have to get your own digital certificate that proves your identity. If you have a Singpass account, you can make use of our nSignSG service to utilise Sign with Singpass, which already comes with a digital certificate ^[2] with your identity as well.

For larger amounts of signatures or if you desire a systematic way of signing and verification, there are workflow solutions such as nSignHub or backend applications like nSignCore to fulfil the requirements. For these, it is best to seek a consultation to work out which solution is a better fit for your requirements.

Signature Verification

As a user, when you receive a digitally signed PDF file, it is important to verify the signature. To do so, utilise PDF applications such as Adobe Reader. When verified, said applications will display the results prominently. Do be wary of applications that display PDF content without verification. Typically, if no results are displayed, no verification is done. For more details, you may refer to this article, which includes detailed examples.

Data Archival

Finally, the digitally signed PDF file needs to be stored securely until it is called upon or the agreement lapses. Conceptually, this is identical to storing signed document papers, except that the ‘digital ink’ doesn’t fade. Consult your organisation’s data retention policies for guidelines.

Conclusion

There is a lot more to know under the hood, but contrary to common belief, you do not need to know everything to work with digital signatures. What we have outlined above covers the basics you will need as a user or when interacting with vendors. If an application is required, it is prudent to involve technical experts to ensure the system and processes are watertight.

To find out more about Digital Signatures or to try some hands-on activities, you can reach out to us to organize a session of Digital Signing 101 Workshop. No cost, no obligations! Just knowledge sharing.

We are also including the answers to some frequently asked questions below that we have encountered before. Check them out.

FAQs

• Can I sign just a section of the file?

This is not possible for PDF signing; digital signatures are applied to the whole document. You can simulate the intent by having certain signers sign at the end of sections instead of at the end of the document.

• I need to make changes after the first signature. How can I do it?

This requires some preplanning. This scenario is typically only required when the next signer needs to put the current date on the form, as compared to the concept of really ‘editing’ the document, which should be finalised before any party signs the document.

First, you must ensure that the fields are not locked after the first signature. This typically means certain settings need to be done depending on which application is used to create the digital signature. Then, changes can still be made on the fields as required.

During this stage, any changes made are reflected and past signed versions can be previewed through Adobe Reader. Here are some examples of how the process will look.

With first signature only: 

With changes applied:

With second signature applied: 

• How can I protect the changes that I have made?

Apply another digital signature on it. Typically, a digital signature should be the last action taken on the file, and it should also lock all fields to prevent further changes afterwards.

• My company’s processes require the signer to sign on every page as an acknowledgement. Can this be done?

Technically, yes. But it is not recommended as every digital signature covers the entire document and comes with its own size overhead. This will bloat up the file size unnecessarily.

It is typically recommended to advise the signer to review the document in its entirety before signing. Alternatively, an electronic signature can be placed on each page to represent the same acknowledgement.

• I have already signed a file, but then I lost my key/token! What should I do?

Well, the good news is the signing process typically embeds your digital certificate (Without the key) into the digital signature, thus ensuring that anyone can verify the signature. So, this does not affect any of the files you have already signed.

However, the bad news is, you will not be able to sign any more files since the key/token is lost. You should also immediately contact the certificate authority to report that this is lost so that they can revoke the certificate to prevent misuse and reissue you a new digital certificate.

• How do I verify a digital signature?

PDF applications like Adobe Reader can be used, it will automatically verify the signature(s) when opening the file. For applications, they can integrate with products which provide an API to verify digital signatures such as nSignCore.

• The digital signature is valid. But how do I know I can trust the person/organisation who signed the file?

First, you must be aware of where the document originates from. If the document came from an organisation, the identity in the signature should be from the organisation or a member of the organisation.

The certificate authority is required to verify the applicant’s identity, including whether they are an authorised staff member from the organisation, before issuing the digital certificate which is signed with a digital signature.

If in doubt, contact the person or organisation to clarify.

• Can someone else see the document content?

Yes, digital signatures does not hide the document content. You can explore encryption (Read up more on our article on Explaining Encryption through real world examples) or utilise password protection measures to fulfil that requirement. 

• Can digital signatures and encryption be used together?

Certainly, they are not mutually exclusive.

• Can someone else tamper with the document content?

It is not possible to edit the document data without breaking the digital signature.

• Can someone else reproduce my digital signature after tampering with the document content?

It is not possible to do that unless they can access the key that comes with your digital certificate. Hence, it is important keep your key/token securely.

• Can I know what has been changed, or revert the document back to the original state?

Digital signatures are designed to flag out tampering, but it is not possible to highlight or revert the changes. Therefore, it is still important to retain a copy of the digitally signed document so that a pristine copy is available when required.

Reference table on the differences between Digital Signatures and Encryption. 

[1] Other than Netrust, signatures signed using Sign with Singpass also enjoy legal presumption. Information is accurate at time of publish.

[2] Certificate is issued from Govtech Certificate Authority upon first attempt to sign using Sign with Singpass.

Follow us on LinkedIn for the latest happenings/updates.

The post Explaining Digital Signatures Through Real World Objects appeared first on Netrust.