New "Encrypt with Module (sn_si.security_incident_Crypto_module)" option on Incident or SIR

Nazim Ansari
Tera Contributor

Hi Community,

 

We recently noticed a change when adding attachments to the Incident (incident) and Security Incident (sn_si_incident) tables.

 

A new option called Encrypt with Module (sn_si.security_incident_Crypto_module) is now available when uploading attachments. If this option is selected, the attachment uploads successfully, but users are unable to view or download the attachment afterwards, even though it appears to be attached to the record.

 

We wanted to check:

  • Has anyone else experienced this behaviour?
  • Is this an expected platform change or a known issue?
  • Are there any prerequisites or additional configurations required before using this encryption module for attachments?
  • If the option is selected accidentally, is there a supported way to recover or decrypt the attachment?

Any insights or recommendations would be greatly appreciated.

Thank you!

1 REPLY 1

Vikram Reddy
Tera Guru

Hi @Nazim Ansari,

 

Nobody flipped a switch on you and it's not corrupting the file, it's the platform's Key Management Framework doing exactly what it's configured to do: encrypt on upload, then refuse to decrypt for anyone the policy doesn't name. Here's the full chain so it's clear why the file "exists" but nobody can open it.

The dropdown itself comes from a record in Encrypted Field Configurations (System Security > Field Encryption > Encrypted Field Configurations). Someone changed the Type: Attachment row on incident and sn_si_incident from Method: Single Module to Method: Multiple Modules. That single field is the whole trigger:

  • Single Module: every attachment gets encrypted with one fixed module, no user choice, no dropdown.
  • Multiple Modules: uploaders see the Encrypt with Module picker and can choose a module, or None to leave it unencrypted.

Encryption itself is part of the free, base Encryption Support capability (the Key Management Framework plugin is active out of the box), so no extra license is needed just to see that option. The catch is on the read side, not the write side: after upload, whether anyone can actually open the attachment is decided entirely by a separate record called a Module Access Policy.

System Security > Key Management > Module Access Policies > New
Cryptographic Module: [the module behind sn_si.security_incident_Crypto_module]
Type: Role
Role: itil (or whatever role your org standardizes on for this data)
Result: Track

If no policy exists for that module, or the logged-in user doesn't hold the role in it, the platform treats the content as invisible, including to the person who uploaded it. That's why upload "succeeds" (upload never checks read access) but view/download fails silently right after, with no error on screen. Worth knowing on the free tier: base Encryption Support caps you at 5 module access policies per instance and blocks scripted encryption, both of which push people to the paid Column Level Encryption Enterprise subscription if you outgrow them.

Configuring or editing Module Access Policies requires the sn_kmf.admin or sn_kmf.cryptographic_manager role, which itself has to be granted by someone holding security_admin, so check who has those roles and whether they set up (or forgot to set up) the policy for this module.

For recovery, there's no self-service decrypt: an admin with sn_kmf.cryptographic_manager needs to either add the right role to that module's access policy so the intended viewers can open it, or, if it was encrypted by mistake, add themselves temporarily, confirm they can open the file, and re-upload it unencrypted (Encrypt with Module: None) if that was the original intent.

If you can confirm which of these two records (Encrypted Field Configuration or Module Access Policy) got touched recently, I'm happy to help narrow down the exact fix.

References

 

Thank you,
Vikram Karety
Octigo Solutions INC