Update: March 5, 2014:

It would appear that the bug described in this post has been addressed in Office 365 Exchange Online OWA, presumably as part of a recently-announce rollout of S/MIME support. Now, when attempting to edit a signed draft in OWA, the following message pops up:

Updated Oct. 19, 2013

Consider the following scenario:

• Compose a message in an S/MIME aware client, such as Outlook.
• Set it to be signed, but don’t send.
• Save it to drafts.
• Login to OWA. (Here, I’m assuming Wave 15 Office 365 Exchange Online, which has a version of OWA which does not support the S/MIME control.)
• Find the saved message in Drafts.
• Resume editing.
• Send.

Here’s the odd part.  If the recipient views the message in an S/MIME aware client, they will see the original draft, not the edited version. If they view the message in a non-S/MIME client, such as OWA, they will see the edited version.

When an S/MIME signed message is sent, it contains two multipart-alternative MIME sections. One is a clear-text version, for the benefit of non-S/MIME aware clients, and the other is the signed version, which has essentially been hashed with the sender’s private key, and is thus unintelligible to non-S/MIME clients.

When the message was edited in OWA, it only knew how to manipulate the clear text version of the message, not the signed part.  When the final message is viewed in an S/MIME aware client, it will preferentially display the signed part, which is unmodified.  In a non-S/MIME-aware client, it only displays the edited clear-text part.

The following two screen grabs are of the same message which was composed as described above, one as viewed in Outlook (which is S/MIME-aware), the other as viewed in OWA (which is non-S/MIME-aware):

Above, we see the body text as it was in the signed draft saved from Outlook. Note that, since Outlook is S/MIME aware, it by default displays the original, unmodified signed MIME part.

Here, we see the version of the message as edited in OWA, the clear-text MIME part.

It is interesting to note some interesting behavior in this context with the Mail application in iOS.  While that app is S/MIME aware, and displays the signed version of the message, the preview text in the message listing is pulled from the clear-text part: